> I'm all for anything that speeds up (and makes more reliable) high network
> speeds, but I often run with 8+ ethernet devices, so IRQs have to be shared,
> and a 10ms lockdown on an interface could lose lots of packets. Although
> it's not a perfect solution, maybe you could (in the kernel) multiple the
> max by the number of things using that IRQ? For example, if you have four
> ethernet drivers on one IRQ, then let that IRQ fire 4 times faster than
> normal before putting it in lockdown...
What you really care about is limiting the total amount of CPU time used for
interrupt processing so that usermode progress is made. The network layer
shows this up paticularly badly because (and its kind of hard to avoid this)
it frees resources on the hardware before userspace has processed them.
Silencing a specific target cannot be done by IRQ masking, you have to
ask the controller to shut up. It may be the default "shut up" handler
is disable_irq but that is non optimal.
Having driver callbacks as part of the irq handler also massively improves
the effect of the event, because faced with an IRQ storm a card can
- decide if it is the guily party
If so
- consider switching to polled mode
- change its ring buffer size to reduce IRQ load and up latency
as a tradeoff
- anything else magical the hardware has (like retuning irq
mitigation registers)
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 07 2001 - 21:00:22 EST