netdev
[Top] [All Lists]

RE: [e1000 2.6 10/11] TxDescriptors -> 1024 default

To: "Jeff Garzik" <jgarzik@xxxxxxxxx>
Subject: RE: [e1000 2.6 10/11] TxDescriptors -> 1024 default
From: "Feldman, Scott" <scott.feldman@xxxxxxxxx>
Date: Thu, 11 Sep 2003 22:13:48 -0700
Cc: <netdev@xxxxxxxxxxx>, <ricardoz@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
Thread-index: AcN4mYdZM4QdDIBwQJeEPlxr+jl3NwATa7zg
Thread-topic: [e1000 2.6 10/11] TxDescriptors -> 1024 default
> Feldman, Scott wrote:
> > * Change the default number of Tx descriptors from 256 to 1024.
> >   Data from [ricardoz@xxxxxxxxxx] shows it's easy to overrun
> >   the Tx desc queue.
> 
> 
> All e1000 patches applied except this one.
> 
> You're just wasting memory.

256 descriptors does sound like enough, but what about the fragmented
skb case?  MAX_SKB_FRAGS is (64K/4K + 2) = 18, and each fragment gets
mapped to one descriptor.  It even gets worse with e1000 because we may
need to split a fragment into two fragments in the driver to workaround
hardware errata.  :-(

It would be interesting to see the frags:skb ratio for 2.6 with TSO
enabled and disabled with Rick's test.  So our effective number of
descriptors needs to be adjusted by that ratio.  I agree with David that
it's wasteful for the device driver to worry about more than
dev->tx_queue_len, but that's in skb units, not descriptor units.

On the other hand, if we're always running the descriptor ring near
empty, we've got other problems.  It seems to reason that it doesn't
matter how big the ring is if we're in that situation.  If the CPU can
overrun the device, expanding the queues between the CPU and the device
may help with bursts but gets you nothing for a sustained load.

I flunked that queuing theory class anyway, so what do I know?  Every
time I get stuck in a traffic slug on the freeway, I think about that
class.  Hey, that means my car is like an skb, so maybe longer roads
would help?  Not!

-scott


<Prev in Thread] Current Thread [Next in Thread>