Re: [E1000-devel] Transmission limit

[Scott Feldman <sfeldma@pobox.com>]

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@freebsd.org/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