众所周知，有两种方法可以避免高负载网络中硬件中断的一些开销，当硬件中断太多时，切换到它们会花费太多时间。这对于程序风格的性能和选择方法非常重要。
- NAPI (New API) - 不使用硬件中断，和polls以太网设备每隔一段时间。 Linux内核默认使用中断驱动模式，只有当传入数据包的流量超过一定阈值时才会切换到轮询模式。
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.
- Interrupt coalescing - 使用硬件中断，但如果中断发生，则禁用中断并启动 poll , 一段时间后，终止轮询并激活中断。
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.
这两种方法都没有显着的中断成本——这是默认中断驱动模式的优势。
但第二种方法 - 中断合并更合理，因为它:
减少延迟 - 包裹到达后，立即尝试立即处理它，如果最近发生了中断，则轮询它。对面的NAPI不会立即处理帧，而是等待一定时间等待下一次轮询。
更少的 CPU 使用率 - 只有当至少有一个数据包已经到来时才开始轮询。但是并不是白做了一次轮询，即使没有收到帧，就好像它做了 NAPI 一样。
IRQ Coalesce 之前的 NAPI 有什么优势？
最佳答案
我将 NAPI 视为中断合并的一种形式。我认为你的问题可能源于对 NAPI 的误解。首先，中断与NAPI有关。此外，NAPI 的投票实际上并非“白费”。请记住，对于 NAPI，其理念是高吞吐量流量是突发的。 NAPI 仅在“数据包接收中断”发生后“启动”。
下面是 NAPI 应该如何使用的快速概述:
内核启动“数据包接收”中断，这是使用 NAPI 的网络设备驱动程序检测到的。网络设备驱动程序然后禁用与接收数据包相关的中断并使用 NAPI，告诉 Linux 网络子系统轮询设备驱动程序。轮询函数由设备驱动程序实现，并传递给网络子系统，并包含设备驱动程序的数据包处理程序。在接收到足够的数据包或达到超时后，重新启用数据包接收中断，一切重新开始。
所以 NAPI 基本上只是 Linux 网络子系统中的一个集中式 API，用于支持中断合并以减少接收活锁情况。 NAPI 为设备驱动程序开发人员提供了一个干净的中断合并框架。 NAPI 不会一直运行，而只会在实际接收到流量时才会运行，这使得它本质上是一种中断合并方案……至少在我的书中是这样。
注意:这都是在使用 NAPI 的网络设备驱动程序的上下文中，但实际上 NAPI 可用于任何类型的中断。这也是 NAPI 的优势之一。
如有理解错误，欢迎指出!
关于linux - NAPI 在 IRQ Coalesce 之前有什么优势？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28090086/