Date: Sun, 8 Dec 2013 13:03:21 +0100 From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de> To: Adrian Chadd <adrian@freebsd.org> Cc: Yong-Hyeon Pyun <pyunyh@gmail.com>, Jack F Vogel <jfv@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, "freebsd-net@freebsd.org list" <freebsd-net@freebsd.org> Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c Message-ID: <9E163DC1-D647-4E19-BE23-44E5DFE2F284@lurchi.franken.de> In-Reply-To: <CAJ-Vmomnu4VLE0Q8A%2BQS6%2B7LA7ry_kD9j05=TvNZeocRjsuE7A@mail.gmail.com> References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <20131202022338.GA3500@michelle.cdnetworks.com> <B9593E83-E687-49E9-ABDC-B2DD615180E9@lurchi.franken.de> <20131203021658.GC2981@michelle.cdnetworks.com> <CAJ-Vmo=kfoPMYjZ0WAtqmoJMz1utXH50SW9N92RA83EMUzY7WA@mail.gmail.com> <B89B1E2D-BAF0-4815-B3AB-EB226F4F76DE@lurchi.franken.de> <CAJ-Vmo=4Zwv5V6ZYDuDLtt%2BowgbvmqyvrnrfnU%2BHeXQ3vAn-KA@mail.gmail.com> <20131205223711.GB55638@funkthat.com> <3576B69E-E943-46E0-83E5-0B2194A44ED0@lurchi.franken.de> <20131206202012.GG55638@funkthat.com> <609C63CD-9332-4EAE-AACE-5B911416DF80@lurchi.franken.de> <CAJ-Vmomnu4VLE0Q8A%2BQS6%2B7LA7ry_kD9j05=TvNZeocRjsuE7A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 7, 2013, at 12:25 AM, Adrian Chadd <adrian@freebsd.org> wrote: > On 6 December 2013 13:10, Michael Tuexen > <Michael.Tuexen@lurchi.franken.de> wrote: > >> Well, this is what happens: >> The sender takes a packet from the send-queue, calls ip-output. Since >> it returns an error, we don't move it to the sent-queue, but leave >> it in the send queue (assuming it doesn't went on the wire). >> However, the driver puts it on the wire, it makes it to the peer, >> the peer sends SACK, and we receive the SACK. Since the packet is >> not on the sent queue, we don't realize that it is acked. Receiving >> a SACK is a trigger for sending a packet. So we take the next one >> from the send-queue (the one from the beginning), and send it again. >> So it is a wire speed ping pong... >> So in case the lower layer tells us that there was a problem in >> sending the packet, we >> * don't consider it sent >> * wait for the next normal protocol trigger for send another packet. >> This sounds OK to me... >> >> That is why I need to know what an error from ip_output() means. >> If I can't conclude that the provided packet was dropped, I can just >> consider it sent and don't try to do any optimisation. > > We're heading down the right path. > > I'm increasingly believing that ignoring the return value is the > correct thing to do. You mean ignoring the return value transport layer? Why not provide a return code which can be used? Returning a value which needs to be ignored doesn't make a lot of sense to me... I think if_transmit() should only return an error if there was a problem with the provided packet, not with some packet, probably a different one. Can you point me to a consumer of the return code of if_transmit(), which can benefit from the logic you described? Best regards Michael > > > -adrian >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9E163DC1-D647-4E19-BE23-44E5DFE2F284>