What are the advantages NAPI before the IRQ Coalesce?

Question

As known there are two approach to avoid some overheads of hardware interrupts in highload networks, when there are too many hardware interrupts, that switching to them takes too much time. It is very important for performance and choosing approach of programm style.

1. NAPI (New API) - Does not use hardware interrupts, and polls the Ethernet-device every certain period of time. The Linux kernel uses the interrupt-driven mode by default and only switches to polling mode when the flow of incoming packets exceeds a certain threshold.

http://en.wikipedia.org/wiki/New_API The kernel can periodically check for the arrival of incoming network packets without being interrupted, which eliminates the overhead of interrupt processing.

2. Interrupt coalescing - Uses hardware interrupts, but if interrupt occur, then disables interrupt and starts poll, for certain period of time, after which the polling is terminated and the interrupt is activated.

https://en.wikipedia.org/wiki/Interrupt_coalescing a technique in which events which would normally trigger a hardware interrupt are held back, either until a certain amount of work is pending, or a timeout timer triggers.

Both approaches have not significant costs of interruption - this is advantage befor default interrupt-driven mode.

But the second approach - Interrupt coalescing is more rational because it:

• Less latency - Once the package arrived, immediately tries to handle it immediately interrupt occurs or poll it if the interrupt has occurred recently. Opposite NAPI will not process the frame immediately, but will wait certain period of time for the next poll.

• Less CPU usage - Starts the poll only if at least one packet has already come. But is not doing a poll in vain, even if frames has not received, as if it did NAPI.

What are the advantages NAPI before the IRQ Coalesce?

Answer 1

I view NAPI as a form of interrupt coalescing. I think your question may stem from a misunderstanding about NAPI. First of all, interrupts are involved with NAPI. Also, NAPI's polling is actually not "in vain". Remember, for NAPI, the idea is that high throughput traffic is bursty. NAPI only "starts" after an "packet received interrupt" happens.

Here's a quick overview of how NAPI is supposed to be used:

The kernel kicks off the "packet received" interrupt, which a network device driver using NAPI detects. The network device driver then disables interrupts related to receiving packets and using NAPI, tells the Linux networking subsystem to poll the device driver. The poll function is implemented by the device driver, and is passed to the networking subsystem, and contains the device driver's packet handler. After enough packets are received or a timeout is reached, packet-receiving interrupts are re-enabled, and everything starts over again.

So NAPI is basically just a centralized API in the Linux networking subsystem for supporting interrupt coalescing to reduce receive livelock situations. NAPI gives device driver developers a clean framework for interrupt coalescing. NAPI does not run all the time, but only happens when traffic is actually received, making it essentially an interrupt coalescing scheme... At least in my book.

Note: This was all in the context of a network device driver using NAPI, but in fact NAPI can be used for any kind of interrupt. This is one of the benefits of NAPI, as well.

If there are any errors in my understanding, please feel free to point them out!

Answer 2

Let's begin with no napi and interupt coalescing.

The first case: livelock. That means when many interrupts post from servel process continuely, the CPU only processes interrupts and never allows a user-level process to run and actually service the requests. For it, we create napi, which handle it with hybrid mode (interupt + polling). When an interrupt happens, handle it and polling for a while to solve subsequence requests.

The second case: optimization. Before raise an interupt, a device first waits for a bit before delivering the interrupt to the CPU. While waiting, other requests may soon complete, and thus multiple interrupts can be merged into a single interrupt delivery, thus lowering the overhead of interrupt processing.

To conclude, there're no conflict between them. And they're for different cases though napi can also optimize the CPU overhead.

Ref: Principles of Computer System Design.