Jason Wright wrote:

> >
> > 1) The end-of-tx interrupt path is significantly longer that necessary
> > 99% of the time - because it always calls qestart.
> 
> Yes, polling the queue in qe_tint() seems pretty cheap, I'll see about
> adding that.

I was thinking of using the flag that indicates the tx is blocked.
> 
> > 2) Better still only enable the TX interrupt when tx flow controlled.
> > Saving 1 interrupt per tx packet is almost certainly measurably faster
> 
> I was more concerned with freeing resources quickly on low memory
> machines.

This driver is transmitting from private buffers - not the user ones -
so it doesn't really matter when you 'reap' the end of tx results.  With
this driver you could do it is the tx-setup path, check the next slot
has been transitted (not owned by MAC) before filling it.

The only case when it is absolutely necessary to take an end of tx
interrupt is when you have transmitted from the users buffer - and the
user can tell when you free it.  (NFS on SVR4 / Solaris does this to
you).  You also do need something to re-enable tx if you run out of tx
space - I've written drivers which enable the end-of-tx IRQ dynamically
in this case, gave a significant improvement.

> > 3) qeintr should (probably) return 1 if it gets past the 'if (!(qecstat
> > & 0xf)) return 0;' bit - otherwise you migth get a 'splurious interrupt'
> > message from the interrupt dispatcher.
> 
> >From my memory, qecstat (global register) is a kind of "something
> interrupted" signal.  It's a quick way to check whether "this channel"
> interrupted.  This is supposed to only happen when qestat has something
> you requested.  (qestat is reset on read, and the relevant portion of
> qecstat is reset when the qestat for that channel is read).  So, a
> spurious interrupt, in theory, shouldn't be possible.

Except that, as in this case, you have already processed the rx frame.
The return value from the intr routine should be 'was your hardware
raising an interrupt' - this is true is qestat is non-zero, regardless
as to whether the isr found any rx or tx frames to process.
> 

> I try avoid it in my drivers (this was added when it was ported to NetBSD =)
> (It's also been added to hme and be, I believe, too... not good for
> performance on v7 cpus).

Fixing the size at 2^n and coding the masks is faster - even if you need
to support variable size rings. 

Yes - even 'x % 2^n' has extra code incase any -ve numbers are
involved.  Code the mask, use unsigned, or take the pipeline hit with
the if (++x == size) x = 0; code.

	David