On Wed, 2004-12-01 at 13:35, Lennert Buytenhek wrote:
> Pretty graph attached. From ~220B packets or so it does wire speed, but
> there's still an odd drop in performance around 256B packets (which is
> also there without your patch.) From 350B packets or so, performance is
> identical with or without your patch (wire speed.)
Seems this is helping PCI nics but not PCI-X. I was using PCI 32/33.
Can't explain the dip around 256B.
> So. Do you have any other good plans perhaps? :)
Idea#1
Is the write of TDT causing interference with DMA transactions?
In addition to my patch, what happens if you bump the Tx tail every n
packets, where n is like 16 or 32 or 64?
if((i % 16) == 0)
E1000_REG_WRITE(&adapter->hw, TDT, i);
This might piss the NETDEV timer off if the send count isn't a multiple
of n, so you might want to disable netdev->tx_timeout.
Idea#2
The Ultimate: queue up 4096 packets and then write TDT once to send all
4096 in one shot. Well, maybe a few less that 4096 so we don't wrap the
ring. How about pkt_size = 4000?
Take my patch and change the timer call in e1000_xmit_frame from
jiffies + 1
to
jiffies + HZ
This will schedule the cleanup of the skbs 1 second after the first
queue, so we shouldn't be doing any cleanup while the 4000 packets are
DMA'ed.
Oh, and change the tail write to
if((i % 4000) == 0)
E1000_REG_WRITE(&adapter->hw, TDT, i);
Of course you'll need to close/open the driver after each run.
Idea#3
http://www.mail-archive.com/freebsd-net@xxxxxxxxxxx/msg10826.html
Set TXDMAC to 0 in e1000_configure_tx.
> > Once or twice it went into a state where it started spitting out these
> > kinds of messages and never recovered:
> >
> > Dec 1 19:13:18 phi kernel: NETDEV WATCHDOG: eth1: transmit timed out
> > [...]
> > Dec 1 19:13:31 phi kernel: NETDEV WATCHDOG: eth1: transmit timed out
> > [...]
> > Dec 1 19:13:43 phi kernel: NETDEV WATCHDOG: eth1: transmit timed out
>
> Didn't see this happen anymore. (ifconfig down and then up recovered it
> both times I saw it happen.)
Well, it's probably not a HW bug that's causing the reset; it's probably
some bug with my patch.
-scott
|