A network adapter does not need to interrupt a CPU for every received packet or completed transmission. Many NICs can hold interrupt delivery briefly and report several completion events together. This interrupt moderation reduces interrupt traffic and CPU entry overhead, but it can also delay the moment software notices newly completed work.

The mechanism sits between packet DMA and the driver’s receive or transmit processing. It changes notification timing; it does not change the packet’s wire format, Ethernet ordering rules, or the basic requirement that the driver eventually process completed descriptors.

Completion and notification are separate events

A typical receive path uses a descriptor ring in host memory. The driver prepares buffers, the NIC writes packet data with DMA, and the device records completion state according to its interface contract. An interrupt can then notify the CPU that work is available.

Those steps are related but not identical:

frame arrives
    |
NIC writes packet data
    |
NIC updates completion state
    |
interrupt moderation policy
    |
interrupt delivered
    |
driver schedules receive processing

A device can therefore have completed DMA work while the CPU has not yet received an interrupt for it. The exact ordering guarantees for descriptor and data visibility belong to the NIC interface, bus architecture, and driver memory-ordering rules; interrupt moderation only controls when notification is emitted within those constraints.

Batching reduces interrupt pressure

Without moderation, a busy queue could generate interrupts at a rate close to its completion rate. Each interrupt can involve hardware delivery, entry into kernel interrupt handling, bookkeeping, and a transition into the driver’s polling path.

Moderation allows multiple completions to share that notification cost. A NIC may implement a timer, a completion-count threshold, or a vendor-specific combination of both. The available controls and their units are device-specific.

This is not equivalent to saying that a larger moderation interval always produces higher throughput. Throughput can be limited elsewhere: link rate, packet processing, memory bandwidth, queue contention, application behavior, or protocol dynamics. Moderation only changes one part of the CPU-notification path.

Linux NAPI changes the role of the interrupt

Linux network drivers commonly use NAPI. In that model, an interrupt does not imply that exactly one packet will be processed in interrupt context. The interrupt signals available work, the driver schedules NAPI polling, and the poll routine processes packets up to its budget.

Conceptually:

NIC interrupt
    |
schedule NAPI
    |
poll receive queue
    |
process several packets
    |
more work?
  /       \
yes       no
 |         |
poll      complete NAPI
again     re-enable notification

This already amortizes per-interrupt cost under load. Hardware interrupt moderation adds another batching point before the interrupt reaches the CPU.

The exact interrupt masking, re-arming, and polling sequence depends on the driver and device. NAPI defines the Linux polling framework, not one universal NIC register model.

MSI-X queues make moderation a per-queue concern

Modern multi-queue NICs often use MSI-X vectors associated with receive/transmit queue groups. Receive Side Scaling can distribute flows among queues, and Linux can steer interrupt vectors toward selected CPUs.

As a result, moderation behavior can interact with queue placement. A heavily loaded queue and a mostly idle queue do not necessarily benefit from identical notification timing. Some hardware and drivers expose adaptive moderation that changes settings according to traffic conditions; others expose fixed parameters or limited controls.

This distinction matters when interpreting aggregate CPU use. A lower system-wide interrupt count can still hide an imbalanced queue that keeps one CPU busy.

Latency cost appears before software sees the packet

If the NIC intentionally waits before issuing an interrupt, an otherwise idle CPU may begin processing the packet later than it would with immediate notification. That added delay is especially visible for sparse traffic because there may be no existing NAPI poll cycle to collect the completion promptly.

Under sustained load, the relationship changes. NAPI may already be polling a busy queue, so packet processing can continue without a fresh interrupt for every arrival. The latency effect therefore depends on traffic pattern, queue state, driver behavior, CPU scheduling, and device policy.

A moderation setting is not a universal latency number. Hardware may interpret timer values differently, adaptive algorithms may alter them, and the host can introduce additional scheduling delay after interrupt delivery.

ethtool exposes device-dependent controls

On Linux, supported interrupt-coalescing parameters can often be inspected with:

ethtool -c eth0

A device that permits changes may accept settings such as:

sudo ethtool -C eth0 rx-usecs 20

The presence, naming, valid range, and effect of parameters depend on the driver and NIC. A value accepted by one adapter cannot be assumed valid or equivalent on another. Some drivers also support adaptive receive or transmit coalescing.

Current interrupt activity can be inspected separately:

cat /proc/interrupts

Queue-specific counters, driver statistics, and application latency measurements provide different views of the system. None alone proves that moderation is the limiting factor.

Tuning is a workload tradeoff

Bulk transfer, packet-forwarding, RPC, storage-over-network, and interactive traffic can place different value on CPU efficiency and notification delay. A configuration suitable for a saturated data path can be undesirable for a latency-sensitive service with sparse requests.

The useful comparison is therefore workload-specific: CPU time, interrupt rate, queue distribution, packet rate, tail latency, and throughput should be measured together. Driver defaults are often designed as general-purpose compromises, while adaptive modes attempt to move that compromise as traffic changes.

Interrupt moderation is ultimately a notification policy. The NIC can finish packet-related DMA work before it signals the CPU, and batching that signal can reduce host overhead. The cost is that software may observe completed work later, with the practical balance determined by the adapter, driver, queue state, and workload.

Networking Linux NIC Interrupts Performance