Polling checks a device for events instead of waiting for the device to signal an interrupt. In a latency-sensitive application, that can make the timing of event checks more controllable: an interrupt may stop application code at an unpredictable moment and introduce a latency spike. section 7.5.2 section 2.3.4
A network driver can poll a network interface card (NIC) for newly arrived packets. Linux uses a hybrid approach: it polls while traffic is present and returns to interrupt-driven operation when traffic stops. Its polling path still uses software interrupts to process packets, so polling does not remove every source of interrupt-related work. section 3.3.1
The choice is a latency trade-off, not a universal optimization:
- Polling gives more control over when checks occur, but repeated checks can do more work than interrupts when no events arrive. section 7.5.2
- Interrupt affinity offers another way to limit interference: assign NIC interrupts to dedicated CPUs and keep application threads on other CPUs. section 3.3.1
Checking a network path
Packets first enter NIC receive queues, then undergo protocol processing that may run on a different CPU from the application thread. When evaluating polling, account for that processing as well as packet arrival, and test the intended production hardware for latency spikes. section 3.3.1 section 2.3.4
Figure 3.3 Packets traversing the network stack
Locates NIC receive queues and protocol processing in the packet path where polling and interrupt work matter. section 3.3.1
