> My fault... I remembered that right after I hit send.  I'll have to
> investigate enabling tx interrupts only when necessary.  (I think I
> tried that at one point in the past and screwed it up somehow).

There is a slight race condition - all tx complete between when you find
there is no space and when you enable the interrupt.  But it is an
extermely unlikely...

Looking at some old code I did this for the driver for the FEPS card
(sun hme driver) and later lance chips, and recall getting a
considerable increase in the max tx rate:
This is from the lance grope code...

    /* The later PCnet parts (probably all except the 79C960) let us
modify
       the interrupt mask (CSR3) while the lance is active.
       Keeping the transmit interrupt disabled most of the time
considerably
       reduces the cost of transmitting packets. */
    
    wr_lance( rap, 3 ); 
    i = rd_lance( rdp );
    if (i == lifp->dev_info.csr3) {
        /* Ok, CRS3 is readable, I guess we can disable the tx
interrupt. */
        i |= CSR3_TINTM;
        lifp->dev_info.csr3 = i;
        wr_lance( rdp, i );
    }
    wr_lance( rap, 0 );


> I think enabling the TX interrupt if OACTIVE is set would work.  I'm
> thinking:
> 
> qestart():
>         move the TX ring reclamation into qestart() (go ahead and reap
>             whatever we can).
>         queue packets, if we run out of room, enable TX interrupts and
>             set OACTIVE
> qe_tint():

If OACTIVE set...
>         unset OACTIVE and call qe_start()
> 

What alignment do you use for the TX and RX buffers?
If you expect to be TXing IP traffic, putting the TX buffers on a 4n+2
boundary is a gain.  Similarly aligning the RX buffers also helps -
unless the sBus card/motherboard has the older DMA+ part which won't do
burst writes if the buffer is misaligned (tx is always ok)

Did consider 32n+2 alignment - just in case bcopy() used features of the
cache controller for cacheline aligned copies - you do have to start
guessing when and where copies take place though :-)

	David