问题描述
众所周知，有两种方法可以避免高负载网络中的一些硬件中断开销，当硬件中断太多时，切换到它们会花费太多时间.这对于程序风格的性能和选择方法非常重要.
- NAPI(新 API) - 不使用硬件中断，并且每隔一段时间轮询以太网设备.Linux内核默认使用中断驱动模式，只有当传入的数据包流量超过一定阈值时才会切换到轮询模式.
http://en.wikipedia.org/wiki/New_API 内核可以定期检查传入的网络数据包的到达而不是中断，这消除了中断处理的开销.
https://en.wikipedia.org/wiki/Interrupt_coalescing 一种技术通常会触发硬件中断的事件是推迟，或者直到完成一定数量的工作，或者超时定时器触发.
这两种方法都没有显着的中断成本 - 这是默认中断驱动模式的优势.
但第二种方法 - 中断合并更合理，因为它:
延迟更短 - 一旦包裹到达，立即尝试处理它，立即中断发生，或者如果最近发生中断，则轮询它.对面的 NAPI 不会立即处理该帧，而是会等待一段时间等待下一次轮询.
更少的 CPU 使用率 - 仅当至少有一个数据包已经到达时才开始轮询.但是不是白做一个poll，即使frames还没有收到，就好像做了NAPI一样.
在 IRQ Coalesce 之前 NAPI 有什么优势?
我将 NAPI 视为一种中断合并的形式.我认为您的问题可能源于对 NAPI 的误解.首先，中断与 NAPI 有关.另外，NAPI 的轮询其实并不是徒劳的".请记住，对于 NAPI，其想法是高吞吐量流量是突发的.NAPI 仅在数据包接收中断"发生后启动".
以下是如何使用 NAPI 的简要概述:
内核启动数据包接收"中断，使用 NAPI 的网络设备驱动程序检测到该中断.然后，网络设备驱动程序禁用与接收数据包相关的中断，并使用 NAPI，告诉 Linux 网络子系统轮询设备驱动程序.poll 函数由设备驱动程序实现，并传递给网络子系统，并包含设备驱动程序的数据包处理程序.在接收到足够的数据包或达到超时后，重新启用数据包接收中断，一切重新开始.
所以 NAPI 基本上只是 Linux 网络子系统中的一个集中式 API，用于支持中断合并以减少接收活锁情况.NAPI 为设备驱动程序开发人员提供了一个干净的中断合并框架.NAPI 并非一直运行，而是仅在实际接收到流量时发生，这使其本质上是一种中断合并方案……至少在我的书中是这样.
注意:这都是在使用 NAPI 的网络设备驱动程序的上下文中，但实际上 NAPI 可以用于任何类型的中断.这也是 NAPI 的优势之一.
如果我的理解有任何错误，欢迎指出！
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.
- 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.
- 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.
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?
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!
这篇关于IRQ Coalesce 之前的 NAPI 有什么优势?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！