[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.WNT.2.00.1007200938030.4488@jbrandeb-desk1.amr.corp.intel.com>
Date: Tue, 20 Jul 2010 10:12:33 -0700 (Pacific Daylight Time)
From: "Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To: Eric Dumazet <eric.dumazet@...il.com>
cc: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"gospo@...hat.com" <gospo@...hat.com>,
"bphilips@...ell.com" <bphilips@...ell.com>,
"Duyck, Alexander H" <alexander.h.duyck@...el.com>
Subject: Re: [net-next-2.6 PATCH] e1000: allow option to limit number of
descriptors down to 48 per ring
On Mon, 19 Jul 2010, Eric Dumazet wrote:
> Le lundi 19 juillet 2010 à 16:43 -0700, Jeff Kirsher a écrit :
> > From: Alexander Duyck <alexander.h.duyck@...el.com>
> >
> > This change makes it possible to limit the number of descriptors down to 48
> > per ring. The reason for this change is to address a variation on hardware
> > errata 10 for 82546GB in which descriptors will be lost if more than 32
> > descriptors are fetched and the PCI-X MRBC is 512.
> > -#define E1000_MIN_TXD 80
> > +#define E1000_MIN_TXD 48
> > #define E1000_MAX_82544_TXD 4096
> >
> > #define E1000_DEFAULT_RXD 256
> > #define E1000_MAX_RXD 256
> > -#define E1000_MIN_RXD 80
> > +#define E1000_MIN_RXD 48
> > #define E1000_MAX_82544_RXD 4096
> So this limit is a pure software one ?
Yes, the hardware will work fine (with the exception of some limits when
certain performance registers are configured like [TR]XDCTL) all the way
down to 1 descriptor, that said, the practical limit is probably more like
8 for RX descriptors, and is 2 * (MAX_SKB_FRAGS + 1) for transmit if TSO
is enabled.
if all offloads are disabled you could run with only 8 tx descriptors, and
I believe it would work fine.
> Why not let an admin chose a lower limit if he wants to ?
I think in this case just to prevent odd interaction bugs with low values
(there would have to be several driver changes and the testing work would
increase to support very low values)
> I am asking because big ring sizes can be a latency source in some
> workloads.
yes, if you are trying to pace traffic in software. That said, at least
on transmit, most frames exit immediately from the hardware unless some
external event like flow control is slowing down transmit.
Jesse
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists