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.

quoted

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