Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 4 Feb 2013 13:28:35 -0500
From:      Randy Stewart <randall@lakerest.net>
To:        Jack Vogel <jfvogel@gmail.com>
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:  <FBC11DFB-BEC7-4025-8F2D-9E2E03CAA0A7@lakerest.net>
In-Reply-To: <CAFOYbcmZU%2B1Ks9962wcEqTVvg5juWYLfePZw8Y0xm%2BKbAvN3qw@mail.gmail.com>
References:  <D3AA078A-CD19-4228-A019-BE9C985895E2@lakerest.net> <CAFOYbcmZU%2B1Ks9962wcEqTVvg5juWYLfePZw8Y0xm%2BKbAvN3qw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
I am beating the heck out of it on my 9.x testbed where I lifted it =
from.

I don't have any ix or ixgbe cards to play with yet though..

R
On Feb 4, 2013, at 1:11 PM, Jack Vogel wrote:

>=20
>=20
> On Mon, Feb 4, 2013 at 9:22 AM, Randy Stewart <randall@lakerest.net> =
wrote:
> All:
>=20
> 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.
>=20
> 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.
>=20
> The patch I have attached makes it so that
>=20
> 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.
>=20
> I have fixed the four intel drivers that had this systemic issue, but =
there
> are still more to fix.
>=20
> Comments/review .. rotten egg's etc.. would be most welcome before
> I commit this..
>=20
> Jack are you out there?
>=20
>=20
> Yes, I'm usually perceived as being 'out there' :)  If you had =
addressed it to 'jfv' rather than 'jv' it would have worked better.
>=20
> I have no theoretical objection to this, how much testing has it had?
>=20
> Jack
>=20

-----
Randall Stewart
randall@lakerest.net







Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FBC11DFB-BEC7-4025-8F2D-9E2E03CAA0A7>