A network interface can receive packets much faster than a CPU should be interrupted for each individual arrival. At high packet rates, one hardware interrupt per packet would consume substantial processor time in interrupt entry, scheduling, driver work, and return paths.
Interrupt coalescing changes that pattern. The adapter waits for a small interval, a packet count, or another implementation-specific threshold before notifying the CPU. Several packet arrivals can then be handled from one notification.
The result is a direct trade: fewer interrupts and lower CPU overhead in exchange for some extra delay before selected packets reach software.
Per-packet interrupts become expensive at high rates
An interrupt transfers CPU attention from current work to a hardware event. That transition has a cost even when the associated driver is efficient.
At low traffic rates, the cost may be minor. At high rates, repeated interrupts can occupy a meaningful share of processor capacity. The problem becomes especially visible with small packets because packet count can rise sharply without a matching rise in total byte throughput.
A 10 Gbit/s link carrying large frames produces far fewer packets per second than the same link carrying short frames. Interrupt pressure therefore follows packet arrival rate more closely than raw link bandwidth.
Modern network stacks also use polling and batched processing techniques, but hardware notification policy remains an important part of the receive path.
Coalescing groups notification work
A NIC can postpone an interrupt after receiving a packet and continue placing later packets into receive buffers. When its coalescing condition is met, it signals the CPU.
The driver then processes multiple completed receive descriptors during one service period. This amortizes interrupt overhead across a batch.
Adapters and drivers expose different controls. Common mechanisms include a timer, a packet or descriptor threshold, or adaptive logic that changes settings according to traffic conditions. Exact names and available ranges vary across hardware and operating systems.
Coalescing can also apply to transmit completion notifications. The same basic principle holds: several completion events can share one CPU notification.
Larger batches reduce notification frequency
More aggressive coalescing generally lowers the number of interrupts generated for a given packet rate.
That can improve CPU efficiency and leave more execution time for application work, protocol processing, storage activity, or other tasks. It can also reduce disruption to CPU caches caused by very frequent transitions into driver processing.
The gain is not unlimited. Large batches require buffer space and processing time, and a busy receive queue can still consume substantial CPU resources after each notification. Coalescing reduces notification overhead; it does not remove the cost of processing packet headers, protocol state, copies, checksums, or application data.
At sufficiently high load, other limits can dominate, including queue capacity, memory bandwidth, CPU affinity, receive-side scaling, and application consumption rate.
Waiting for a batch adds latency
The first packet in a coalescing interval may sit in a receive buffer while the adapter waits for the notification condition.
That delay can be tiny, but latency-sensitive workloads can detect it. Interactive traffic, real-time control, high-frequency messaging, and tightly measured request-response services may favor shorter coalescing intervals than bulk data transfer.
A packet that arrives just before an interrupt is triggered experiences little added waiting. A packet that starts a fresh timer can experience more. Coalescing therefore affects not only average latency but potentially latency variation.
Reducing the delay usually increases interrupt frequency. There is no single setting that simultaneously minimizes notification overhead and packet delivery delay across every workload.
Adaptive moderation changes settings with traffic
Some adapters and drivers support adaptive interrupt moderation. Instead of holding one fixed delay or packet threshold, the system changes its policy according to observed traffic.
Light traffic can use prompt notification to keep latency low. Heavy traffic can shift toward larger batches to control interrupt rate.
Adaptive behavior makes benchmark interpretation more complicated. A short test and a sustained high-rate test can exercise different moderation states even on the same machine. Traffic direction, packet size, queue count, and CPU placement can also alter the result.
For repeatable measurements, record the adapter’s moderation mode and relevant driver settings alongside workload parameters.
Multiple receive queues distribute the work
Modern NICs often provide several receive queues. Receive-side scaling can steer different traffic flows to different queues and CPUs, allowing packet processing to run in parallel.
Each queue can have its own interrupt vector or related notification mechanism, depending on the device and platform. Coalescing then interacts with queue distribution.
Adding queues can spread processing across cores, but it can also increase the number of active interrupt sources. Aggressive coalescing may reduce interrupt pressure per queue, while poor queue placement can still create hot CPUs or cache movement.
Queue count, interrupt affinity, flow steering, and coalescing settings should therefore be evaluated together rather than as isolated controls.
Throughput tests and latency tests need different measurements
A throughput benchmark can show a benefit from interrupt coalescing because reduced CPU overhead leaves more capacity for moving data. That result does not establish that the same setting is suitable for a latency-sensitive service.
Latency testing should include distribution data such as median and tail latency, not only an average. Packet rate and CPU utilization should be recorded at the same time.
Interrupt counts provide another useful signal. If a configuration moves the same traffic with far fewer interrupts while CPU use falls, coalescing is likely contributing to the efficiency gain. If tail latency rises at the same time, the tradeoff is visible in both directions.
Tests should keep packet size, queue configuration, CPU affinity, power policy, and application load consistent. Changing several factors at once makes the source of a performance shift difficult to isolate.
Coalescing is a scheduling trade at the device boundary
Interrupt coalescing lets a network adapter convert many packet events into fewer CPU notifications. It does not combine the packets themselves or alter their network protocol semantics. The packets remain separate receive units; only the timing of software notification and batch processing changes.
The practical effect depends on traffic rate and service goals. Bulk transfer often benefits from reduced interrupt overhead. Latency-sensitive traffic can favor faster notification, especially when CPU capacity is already sufficient.
The useful setting is therefore the one that meets the system’s latency target while keeping interrupt and packet-processing cost within available CPU capacity.