On Wed, Jan 23, 2002 at 12:44:23PM +0000, David Laight wrote:
> > 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.
> 
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).

> 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.
> 
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():
	unset OACTIVE and call qe_start()

> 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.

True enough, and it simplifies the handler a bit.

--Jason L. Wright