Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should q.xmit return value be ignored? #392

Open
emillon opened this issue Feb 3, 2019 · 1 comment
Open

Should q.xmit return value be ignored? #392

emillon opened this issue Feb 3, 2019 · 1 comment

Comments

@emillon
Copy link

emillon commented Feb 3, 2019

Originally posted by @cfcs in #370 (comment)

@avsm Do you remember what this function (xmit) actually does?

@hannesm suggested that we could make it log when we get a Error _, but I can't figure out if this is supposed to fail, and I felt reluctant to add it in case it was supposed to fail 10k times per second in some cases. If it is not supposed to fail often, I think adding a warning message to the log sounds like a very sensible suggestion, especially if it is supposed to never fail and there are bugs to be fixed hiding in here.

@yomimono
Copy link
Contributor

yomimono commented Mar 8, 2019

xmit will be some invocation of WIRE.xmit which is this function. It should fail only if the buffer given is too small or if the underlying interface fails to write the IP packet, if I'm reading correctly.

hannesm added a commit to hannesm/mirage-tcpip that referenced this issue Feb 7, 2020
hannesm added a commit that referenced this issue Feb 7, 2020
tcp: ignore result of xmit, continues #310, see #392
hannesm added a commit to hannesm/opam-repository that referenced this issue Feb 8, 2020
CHANGES:

* Revert "Ipv4.Fragments use a Lru.M.t instead of Lru.F.t" (mirage/mirage-tcpip#423 by @hannesm)
  A Lru.M.t allocates a Hashtbl.t of size = capacity (= 256 * 1024 in our case),
  this leads to excessive ~2MB memory consumption for each Fragment cache,
  reported by @xaki23 in mirage/qubes-mirage-firewall#93
* use SOCK_RAW for an ICMP socket in the unix sockets API (previously used
  SOCK_DGRAM which did not work)
  reported by @justinc1 in mirage/mirage-tcpip#358, fixed in mirage/mirage-tcpip#424 by @hannesm
* tcp is now compatible with lwt >= 5.0.0 (where Lwt.async requires a function
  of (unit -> unit Lwt.t) (mirage/mirage-tcpip#370 mirage/mirage-tcpip#425 @cfcs @hannesm, issue mirage/mirage-tcpip#392 @emillon)
* Add a dependency on dune-configurator to support dune 2.0.0 (mirage/mirage-tcpip#421 @avsm)
mgree pushed a commit to mgree/opam-repository that referenced this issue Feb 19, 2020
CHANGES:

* Revert "Ipv4.Fragments use a Lru.M.t instead of Lru.F.t" (mirage/mirage-tcpip#423 by @hannesm)
  A Lru.M.t allocates a Hashtbl.t of size = capacity (= 256 * 1024 in our case),
  this leads to excessive ~2MB memory consumption for each Fragment cache,
  reported by @xaki23 in mirage/qubes-mirage-firewall#93
* use SOCK_RAW for an ICMP socket in the unix sockets API (previously used
  SOCK_DGRAM which did not work)
  reported by @justinc1 in mirage/mirage-tcpip#358, fixed in mirage/mirage-tcpip#424 by @hannesm
* tcp is now compatible with lwt >= 5.0.0 (where Lwt.async requires a function
  of (unit -> unit Lwt.t) (mirage/mirage-tcpip#370 mirage/mirage-tcpip#425 @cfcs @hannesm, issue mirage/mirage-tcpip#392 @emillon)
* Add a dependency on dune-configurator to support dune 2.0.0 (mirage/mirage-tcpip#421 @avsm)
djs55 pushed a commit to djs55/mirage-tcpip that referenced this issue Apr 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants