--- title: "Fewer NIC Interrupts Do Not Establish Lower Application Latency" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/nic-interrupt-moderation-napi-packet-latency" last-updated: "2026-10-20" --- # Fewer NIC Interrupts Do Not Establish Lower Application Latency Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. Fewer NIC hardware interrupts establish fewer counted notifications over the stated interval. They do not establish faster application completion. Compare receive-packet observations, notification counts, polling activity and application responses separately, then judge the offered GPU host against the required completion boundary under comparable traffic and host load. ## Follow the notification into host processing A NIC can receive packets before it notifies the host about their arrival. Hardware interrupt moderation can defer or combine those notifications. Intel's Ethernet Adapters and Devices User Guide 30.1.1, dated June 19, 2025, describes potential CPU-efficiency gains alongside added packet-handling latency. That Windows-oriented description supplies a tradeoff example, rather than a Linux driver specification. NAPI explains the Linux processing side. In Linux 6.6's documented basic path, a device interrupt leads to scheduling a NAPI instance whose driver poll handles work. In that interrupt-driven path, the driver keeps the relevant interrupt masked during polling; outstanding receive work can lead to another poll without a fresh interrupt. Polling can also occur without a preceding device interrupt. The reference explicitly says NAPI supplies no explicit event coalescing by default; usual batching comes from device IRQ coalescing. Notification coalescing and NAPI processing therefore describe distinct mechanisms. Linux 6.6 also leaves instance-to-queue-and-interrupt mapping flexible. The supplied interface's mapping needs its driver context. References: [NI1](https://docs.kernel.org/6.6/networking/napi.html), [I1](https://edc.intel.com/content/www/us/en/design/products/ethernet/adapters-and-devices-user-guide/30.1.1/interrupt-moderation-rate/) ## Keep four observation types separate Read a receive report as four separate accounts. A device IRQ count records the hardware interrupt events covered by its definition. A NAPI poll-invocation count records calls to the driver's processing method. A receive-packet count records a defined traffic population at a named observation point. An application-completion count records the application events chosen for the requirement. None is a substitute unit for the others. Before using an IRQ total, ask whether it covers the intended receive path or also includes other queues, transmit events or device activity. Retain the interval and exact counter definition. A whole-adapter total and a selected receive-path total need not have the same scope. The linked RSS guide addresses flow-to-queue distribution. The TSO/GSO/GRO guide addresses changes in host and wire packet representations. Resolve those population questions there; this comparison holds the receive observation definition fixed and asks what the notification count establishes. References: [NI1](https://docs.kernel.org/6.6/networking/napi.html) ## Compare 1,000 packet observations with 20 and 100 interrupts Invent reports A and B for two candidate receive paths observed for equal one-second intervals. Both use the same stipulated receive-packet definition: one observation per received data frame at a named NIC ingress observation point, before any host receive aggregation. Each report records 1,000 such observations. Restrict the IRQ account in both reports to the device interrupts associated with the compared receive path. These are invented accounting inputs, with no actual adapter, counter field or benchmark behind them. A records 20 device interrupts; B records 100. The ratios are 1,000 / 20 = 50 observed packets per interrupt for A and 1,000 / 100 = 10 for B. A has one fifth as many counted interrupts over an equal interval. Both reports contain the same number of defined receive-packet observations. Those means do not allocate packets to actual notifications. A does not establish 20 batches of 50, and B does not establish 100 batches of 10. Neither supplies a distribution of packets handled per poll, a poll count or one poll per interrupt. Recovering such relationships would require observations linking the relevant events, including work crossing the interval boundaries. The fictional reports also contain no CPU-time account, transmitted-traffic baseline, drop observation, application completion or timestamp. They cannot establish CPU-time savings, loss, successful application delivery or latency. Equal receive totals leave arrival timing and later processing unspecified. Nothing here ranks A's application response ahead of B's. ## Notification efficiency and packet waiting need separate evidence Imagine an application request needing an incoming message. If the relevant packet arrives while a notification is being deferred, some of its elapsed time can pass before host processing is prompted. If several packets arrive close together, sharing notification work can make that work less frequent. These possibilities explain why notification efficiency and packet waiting deserve separate evidence. Return to A and B. Their one-second totals could coexist with different arrival, waiting and processing timelines. Even equal average response times would leave the slower responses unresolved. A buyer concerned with the 99th percentile needs that stated percentile at the required application boundary, with the measurement population and duration attached. The missing information cannot be reconstructed by treating the observation rate as even spacing between packets or by distributing the interval equally among interrupts. Those would be new timing assumptions, absent from both reports. Fewer notifications are compatible with several response outcomes; they do not select the faster one. References: [I1](https://edc.intel.com/content/www/us/en/design/products/ethernet/adapters-and-devices-user-guide/30.1.1/interrupt-moderation-rate/) ## Ask what an adaptive algorithm treats as better An adaptive label needs its objective. Linux 6.6's Net DIM documentation describes comparing driver-supplied byte, packet and event samples together with elapsed time. It gives bandwidth improvement priority, then packet-rate improvement when bandwidth is unchanged; interrupt-rate reduction comes afterward when the other rates are unchanged, subject to the algorithm's significance checks. Net DIM does not collect those measurements itself. It suggests moderation changes for the registered driver to apply, and the driver can condition its response. This documents one available mechanism, rather than proving that an offered NIC uses it. An algorithm can therefore rate a sample better without establishing the required tail latency. Ask which mechanism the offered driver uses and what application-response evidence accompanies its efficiency claim. References: [NI2](https://docs.kernel.org/6.6/networking/net_dim.html) ## Choose against the application response requirement Define the completion boundary before comparing offers. For a GPU-serving example, a buyer might require elapsed time from a client issuing a request to that client receiving the complete response. A report ending when the server host observes the input packet covers only part of that interval. If a different boundary is required, state its start and finish just as explicitly. Ask for evidence on the actual NIC model, firmware, driver and kernel combination, including whether the receive path in question uses the documented Linux mechanisms. Keep packet sizes, protocol and flow mix, burst pattern, offered load, concurrent host/application work and relevant receive-path configuration comparable. Explain differences between candidates before attributing a response change to interrupt moderation. For a tail-latency requirement, retain the stated percentile, time units, sample count and observation duration, plus the completed-operation rate and the treatment of failed, timed-out or unfinished requests. A percentile calculated only from completed requests can leave excluded requests unrepresented. The evaluation should account for the requested work and any requests omitted from the timing population. Use IRQ and polling observations to help explain that result. If CPU efficiency is a separate purchasing requirement, request CPU-time evidence within a defined scope. When an offer supplies only a lower IRQ total, record application responsiveness as unresolved and request the missing response evidence. The appropriate selection follows the required result under the comparable workload. ## Use actual physical ports for the cabling inquiry Interrupt counts add no physical cable endpoints. Once platform and network owners select the equipment and approve its connections, use the actual port and patching schedule for any cabling inquiry. Leviathan's Structured Cabling & Fiber Installation service can discuss routing, dressing, labeling and agreed connection records for compatible customer-furnished or separately sourced assemblies. Use the related service and project-inquiry links to share the approved endpoints, routes, materials responsibilities, site access and required records. Driver and software tuning, NIC configuration and application-performance evaluation remain with the appointed technical owners. This article supports equipment comparison; it supplies no procedure or work approval. References: [L1](https://www.leviathansystems.co/services/structured-cabling) ## Primary sources - [NI1 — Linux 6.6: NAPI](https://docs.kernel.org/6.6/networking/napi.html). Checked 2026-10-20. Versioned polling, interrupt masking, flexible queue mapping and default coalescing distinctions; actual receive behavior requires the offered driver context. - [NI2 — Linux 6.6: Net DIM — Generic Network Dynamic Interrupt Moderation](https://docs.kernel.org/6.6/networking/net_dim.html). Checked 2026-10-20. Driver-supplied samples and the documented objective ordering; applicability depends on the offered driver's use of this mechanism. - [I1 — Intel Ethernet Adapters and Devices User Guide 30.1.1: Interrupt Moderation Rate](https://edc.intel.com/content/www/us/en/design/products/ethernet/adapters-and-devices-user-guide/30.1.1/interrupt-moderation-rate/). Checked 2026-10-20. June 19, 2025 edition. Windows-oriented CPU-efficiency and handling-latency tradeoff; no setting or measured result is transferred to Linux. - [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Physical routing, assembly installation, labels and agreed connection records with identified materials responsibilities. ## Related Leviathan resources - [RSS receive queues and physical port capacity](/articles/nic-rss-receive-queues-versus-port-capacity) - [TSO, GSO and GRO: host versus wire packet counts](/articles/nic-segmentation-offload-host-versus-wire-packets) - [Switch forwarding modes and latency measurement boundaries](/articles/gpu-switch-cut-through-versus-store-and-forward-latency) - [Structured Cabling & Fiber Installation](/services/structured-cabling) - [Discuss the approved physical connection package](/contact?service=structured-cabling&from=%2Farticles%2Fnic-interrupt-moderation-napi-packet-latency) ## Scope cabling for the selected physical connections Share the approved port and patching schedule, routes, materials responsibilities and required connection records to discuss physical installation scope and availability. [Discuss the scope](/contact?service=structured-cabling&from=/articles/nic-interrupt-moderation-napi-packet-latency)