> This looks good, except that I am somewhat concerned about...
> 
> > 		Loop over the software interrupts until no more are pending
> > 		and unmasked.
> 
> This makes sense, but I am leery of having a loop in the interrupt
> handler.  

If you don't have the loop, you can have some rather odd performance
anomolies -- the softint handler will typically run again on the
"next" interrupt, but that may not be until many milliseconds later..

A couple cases to worry about:

 - next hardware interrupt comes in while running the softint handler.
 - next hardware interrupt comes in while running  a "later" softint handler.
 - softint A can post softint B, softint B can post softint A.

> This is probably just superstition on my part.  

Well-founded superstition...  if the hard interrupt rate is high
enough that the softints and/or userland never get to run to dequeue
the stuff you "livelock".  To avoid livelock, the dequeue "process"
and everything downstream needs to run at higher priority than the
enqueue "process"; however, many NIC's have not had a lot of
buffering, and running that way leads to greater packet loss when you
have bursts of back-to-back packets..

As I think has been discussed here recently (or maybe it was over on
tech-net), the "conventional wisdom" is to use NICs which allow for
enough receive buffering to absorb large bursts and adaptively switch
to polling when the arrival rate exceeds some threshold.

					- Bill