> > (note that in case of shared interrupts, another 'innocent' device might
> > stay disabled for some short amount of time as well - but this is not an
> > issue because this mitigation does not make that device inoperable, it
> > just delays its interrupt by up to 10 msecs. Plus, modern systems have
> > properly distributed interrupts.)
>
> 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.
Yes, any interrupt mitigation should depend on the interrupt type - and
only the driver knows which interrupts are urgent.
Unconditionally disabling an interrupt for 10 ms is bad.
An idea for a network driver:
Under load TxDone (one packet finished) is unimportant, TxIdle (Tx
process stopped due to out of buffers) while netif_stop_queue() must be
handled ASAP.
I've tried a driver that disabled TxDone and TxIdle entirely while not
netif_stop_queued, only if the queue was stopped it enabled them. A
timer handled TxDone and start_xmit polled for TxDone, too.
Result: the performance for bulk TCP transfers was around 30 % higher.
But the 10ms timer latency killed the performance of 'ping -l'.
bcrl could you try that with ns83820?
* Do not use the interrupt holdoff register - it might hold off urgent
interrupt sources.
* instead disable TxDone and/or RxDone if too many interrupt arrive
/sec.
* I think the ns83820 has a general purpose timer interrupt, correct?
Set it to 400 us.
* If the timer interrupt occurs and neither TxDone nor RxDone are set,
then disable the timer and switch back to unmitigated TxDone, RxDone
interrupts.
Then you can limit the interrupts without sacrifying immediate response
to TxIdle while in netif_stop_queue() state.
-- Manfred - 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:18 EST