A network interface can receive packets faster than a CPU should service one hardware interrupt per packet. Interrupt coalescing addresses that mismatch by allowing the adapter to group completion notifications and interrupt the CPU less often.
The tradeoff is explicit. Fewer interrupts reduce interrupt handling and scheduling pressure, but a packet may wait longer before software is told that receive work is ready. The best setting depends on packet rate, latency targets, CPU capacity, and the adapter’s coalescing controls.
Packet arrival and interrupt delivery are separate events
A received frame first reaches the network adapter. The adapter validates and places packet data or descriptors into host-visible receive structures according to its driver and DMA design.
The adapter then needs to signal that software has work to process. On modern systems this signal is commonly an MSI or MSI-X interrupt rather than a legacy shared interrupt line.
Those two events do not have to occur at the same instant. A NIC can receive several packets, update several completion entries, and issue one interrupt covering the accumulated work.
This separation is the basis of interrupt coalescing.
One interrupt per packet can waste CPU time
At low packet rates, immediate notification is inexpensive and gives software a prompt signal. At high rates, the same policy can produce a large number of interrupts.
Each interrupt has processing cost. The processor changes execution context, runs interrupt-related kernel work, and may disturb useful application execution and cache locality. Even when each event is cheap, a very high event rate can consume substantial CPU time.
Grouping notifications amortizes that fixed work across multiple packets. If one interrupt leads software to process 32 receive completions, the notification cost per packet can be much lower than with 32 separate interrupts.
The saved CPU capacity can increase sustainable packet throughput or leave more processor time for application work.
Coalescing can use packet counts, timers, or both
Hardware implementations vary, but two common controls are a packet threshold and a timer.
A packet threshold asks the adapter to signal after enough completions have accumulated. This works well during busy periods because the threshold can be reached quickly.
A timer limits how long work waits when traffic is sparse. Without a time bound, a threshold of 32 packets could leave a lone packet waiting indefinitely for 31 more arrivals.
Adapters can combine these mechanisms. An interrupt may occur when a completion count is reached or when a timer expires, whichever condition occurs first.
Exact controls, units, and limits are device-specific. Driver interfaces often expose only the settings supported by the active hardware and driver.
Added delay is most visible at low queue depth
Coalescing delay is not the same as transmission time on the wire. It is time inserted between completion activity and CPU notification.
For a bulk transfer with many packets already arriving, a packet threshold may be reached almost immediately. The extra delay per batch can be small relative to the throughput benefit.
For sparse request-response traffic, the first packet in a batch may have no following traffic to trigger a count threshold quickly. A timer-based limit then becomes important, and its configured interval can become visible in tail or application latency.
This makes aggressive coalescing less attractive for workloads where microseconds of response time matter more than maximum packet rate.
Larger batches change work distribution
Interrupt reduction does not eliminate packet processing. It changes when that processing is requested and how much work can be available at once.
A larger batch can improve amortization and cache behavior, but it can also create bursts of kernel work. Other tasks sharing the CPU may see longer intervals before they run if receive processing consumes a large budget in one pass.
Operating-system networking mechanisms can place additional limits on work per polling cycle or defer remaining work. Those controls interact with NIC interrupt behavior, so a coalescing setting cannot be evaluated solely from the hardware interrupt counter.
Useful measurements include packet rate, interrupt rate, CPU utilization, receive drops, application latency, and per-queue load.
Receive queues can have separate interrupt paths
Modern multiqueue NICs commonly expose several receive queues and use MSI-X vectors so queues can have distinct interrupt paths.
This permits traffic processing to spread across CPUs. It also means interrupt coalescing is part of a larger queue-placement design. A low interrupt rate on one queue does not prove that the whole adapter is balanced.
Receive Side Scaling can steer flows to queues, while interrupt affinity determines which CPUs handle the associated notifications. Coalescing then controls notification frequency for the work accumulating on those queues.
A tuning change can therefore move a bottleneck rather than remove it. Reducing interrupts may free CPU time, but poor queue distribution can still overload one core while others remain lightly used.
Adaptive schemes change settings with traffic
Some drivers and adapters support adaptive interrupt moderation. Instead of keeping one fixed delay or threshold, the system changes moderation according to observed traffic conditions.
The goal is to favor prompt notification at lower rates and stronger batching when packet rates rise. This can provide a useful compromise for machines that alternate between interactive traffic and bulk transfers.
Adaptive behavior also makes measurements less static. The effective interrupt pattern can change as traffic changes even when an administrator has not edited a setting.
For repeatable performance tests, record whether adaptive moderation is active along with the visible coalescing parameters.
Lower interrupt counts do not guarantee lower latency
An interrupt counter is easy to observe, but minimizing it is not a complete performance objective.
Very aggressive batching can produce an impressive reduction in interrupts while increasing request latency. Very weak batching can keep notification delay low while consuming CPU capacity that the application needs.
The useful target is enough moderation to control notification overhead without violating the workload’s latency and throughput requirements.
That balance can differ between a storage server carrying large transfers, a packet-processing host handling millions of small packets, and an interactive service dominated by short request-response exchanges.
Hardware offloads affect the same measurements
Interrupt coalescing operates alongside other NIC and kernel mechanisms. Receive aggregation, checksum offload, segmentation features, queue steering, and polling behavior can all change the amount of work associated with an interrupt.
As a result, packets per interrupt is not a universal measure of efficiency. A single interrupt can correspond to different amounts of protocol work on different systems or under different offload settings.
Comparisons are most useful when hardware, driver, queue count, offload configuration, traffic shape, and CPU placement are held constant.
The practical control is notification frequency
Interrupt coalescing does not make packet processing free and does not increase link speed. It controls how frequently the adapter asks the CPU to service completed network work.
Shorter delays and smaller batches favor prompt notification. Longer delays and larger batches favor lower interrupt overhead. Traffic rate determines how quickly thresholds fill, while timers place a bound on waiting when traffic is light.
The resulting setting is a latency-versus-CPU decision. Measure both sides of that exchange under the actual traffic pattern rather than treating the smallest interrupt count as the best result.