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/