On Tue, May 09, 2000 at 12:43:13AM -0700, Hal Murray wrote:

 > The fxp driver doesn't use transmit interrupts.  Under normal traffic 
 > patterns this works fine.  The work gets done on the next receive 
 > interrupt, saving the CPU cycles that would have been burned by the 
 > overhead on each transmit interrupt. 

Actually, yes, the fxp driver *does* use transmit interrupts.  If you
take a look at fxp_start(), at the end of that function:

	if (sc->sc_txpending != opending) {
		.
		.
		.
		/*
		 * Cause the chip to interrupt and suspend command
		 * processing once the last packet we've enqueued
		 * has been transmitted.
		 */
		FXP_CDTX(sc, sc->sc_txlast)->cb_command |=
		    htole16(FXP_CB_COMMAND_I | FXP_CB_COMMAND_S);
		FXP_CDTXSYNC(sc, sc->sc_txlast,
		    BUS_DMASYNC_PREREAD|BUS_DMASYNC_PREWRITE);
		.
		.
		.
	}

Note that there is no race condition here, because the command block
preceeding that one is not allowed to access it until this operation
is completed.

 > I found the place in the code where it sets up the transmit command.  
 > (That's not hard, the symbol is only used once.)  When I or-ed in 
 > the interrupt bit, things worked as expected.  (I forget to measure 
 > how much more CPU that used.) 

What version of NetBSD are you using?  The piece I quoted here is
from NetBSD-current.

 > On a pair of 400 MHz Celerons, throughput drops from 90 megabits 
 > with the window under 190K bytes to under 20 when the window is over 
 > 195K bytes. 

With the driver in NetBSD-current, I am getting 85-90Mb/s w/ the fxp
driver between similar machines, tho I'll see if I can reproduce this
problem with a > 195K window.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>