Subject: Re: splserial() higher than splhigh()?
To: David Querbach <firstname.lastname@example.org>
From: Bill Sommerfeld <email@example.com>
Date: 02/01/2001 09:21:13
> 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
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.