Re: Today Linus redesigns the networking driver interface

Colin Plumb (colin@nyx.net)
Tue, 22 Sep 1998 14:03:41 -0600 (MDT)


Linus explains why you can want a bh marked but *not* want to process
it immediately, for batch-mode efficiency gains, but ends by worrying:

> (Aggregation tends to be bad for latency, which is why it's hard: there
> needs to be some way for the interrupt handler to tell the system that "I
> want bh's run _now_, because I got an important packet or I'm close to
> filling up the queues").

Easy fix: add a second bitmask that is *not* normally checked on interrupts
retusn, and a mark_bh_lazy() function that sets bits there.

If you do an ordinary mark_bh, the both bits are cleared and the whole
chain is run. If you mark_bh_lazy, then the chain will get run
eventually "when it's convenient". Suggestions include:
- Before dropping into the idle task.
- On a timer tick.
- On a task switch (maybe a switch to a non-RT task?)

This makes things like the serial port easy:

- get character
- Stuff into buffer
- If buffer getting full, or end of packet seen, or low-latency requested,
or...
mark_bh()
else
mark_bh_lazy()

This somehow feels a lot cleaner to me than messing with the return value
from interrupt handlers.

(What I *would* like to see a return value indicating is "I found work to do
at my interrupt source", as opposed to "that interrupt wasn't generated by
*my* piece of hardware", which would permit spurious interrupt detection,
and thus interrupt autoprobing, even on shared interrupt lines.)

-- 
	-Colin

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/