As Few Interrupts as Possible

Onload User Guide (UG1586)

Document ID
Release Date
1.2 English

A tuned application will reach a balance between the number/rate of interrupts processed and the amount of real work that gets done, for example by processing multiple packets per interrupt rather than one. Even spinning applications can benefit from the occasional interrupt. For example when a spinning thread has been de-scheduled from a CPU, a timeout interrupt will prod the thread back to action after 250 µs.

# onload_stackdump lots | grep ^interrupt
Table 1. Onload_stackdump Interrupt Counters
Counter Description
Interrupts Total number of interrupts received for the stack.
Interrupt polls Number of times the stack is polled - invoked by interrupt.
Interrupt evs Number of events processed when invoked by an interrupt.
Interrupt wakes Number of times the application is woken by interrupt.
Interrupt primes Number of times interrupts are re-enabled (after spinning or polling the stack).
Interrupt no events Number of stack polls for which there was no event to recover.
Interrupt lock contends The application polled the stack and has the lock before an interrupt fired.
Interrupt budget limited Number of times, when handling a poll in an interrupt, the poll was stopped when the NAPI budget was reached. Any remaining events are then processed on the stack workqueue.


If an application is observed taking lots of interrupts it might be beneficial to increase the spin time with the EF_POLL_USEC variable or setting a high interrupt moderation value for the net driver using ethtool. You should also ensure that the application CPU cores are isolated to avoid descheduling. If it is not possible to isolate the cores, consider switching to interrupt mode.

The number of interrupts on the system can also be identified from /proc/interrupts.