Date: Mon, 4 Feb 2013 10:11:03 -0800 From: Jack Vogel <jfvogel@gmail.com> To: Randy Stewart <randall@lakerest.net> Cc: Kip Macy <kmacy@freebsd.org>, John Baldwin <jhb@freebsd.org>, freebsd-net <freebsd-net@freebsd.org>, Robert Watson <rwatson@freebsd.org>, Jack F Vogel <jfv@freebsd.org> Subject: Re: Driver patch to look at... Message-ID: <CAFOYbcmZU%2B1Ks9962wcEqTVvg5juWYLfePZw8Y0xm%2BKbAvN3qw@mail.gmail.com> In-Reply-To: <D3AA078A-CD19-4228-A019-BE9C985895E2@lakerest.net> References: <D3AA078A-CD19-4228-A019-BE9C985895E2@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 4, 2013 at 9:22 AM, Randy Stewart <randall@lakerest.net> wrote: > All: > > I have been working with TCP in gigabit networks (igb driver actually) and > have > found a very nasty problem with the way the driver is doing its put back > when > it fills the out-bound transmit queue. > > Basically it has taken a packet from the head of the ring buffer, and then > realizes it can't fit it into the transmit queue. So it just re-enqueue's > it > into the ring buffer. Whats wrong with that? Well most of the time there > are anywhere from 10-50 packets (maybe more) in that ring buffer when you > are > operating at full speed (or trying to). This means you will see 10 > duplicate > ACKs, do a fast retransmit and cut your cwnd in half.. not very nice > actually. > > The patch I have attached makes it so that > > 1) There are ways to swap back. > 2) Use the peek in the ring buffer and only > dequeue the packet if we put it into the transmit ring > 3) If something goes wrong and the transmit frees the packet we dequeue it. > 4) If the transmit changed it (defrag etc) then swap out the new mbuf that > has taken its place. > > I have fixed the four intel drivers that had this systemic issue, but there > are still more to fix. > > Comments/review .. rotten egg's etc.. would be most welcome before > I commit this.. > > Jack are you out there? > > Yes, I'm usually perceived as being 'out there' :) If you had addressed it to 'jfv' rather than 'jv' it would have worked better. I have no theoretical objection to this, how much testing has it had? Jack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFOYbcmZU%2B1Ks9962wcEqTVvg5juWYLfePZw8Y0xm%2BKbAvN3qw>