众所周知，有两种方法可以避免高负载网络中硬件中断的一些开销，当硬件中断太多时，切换到它们会花费太多时间。这对于性能和程序风格的选择非常重要。
-
NAPI（新API） http://en.wikipedia.org/wiki/New_API - 不使用硬件中断, and polls http://en.wikipedia.org/wiki/Polling_(computer_science)以太网设备每隔一段时间。 Linux内核默认使用中断驱动模式，只有当传入数据包的流量超过一定阈值时才切换到轮询模式。
http://en.wikipedia.org/wiki/New_API http://en.wikipedia.org/wiki/New_API内核可以定期地
查看用于传入网络数据包的到达没有存在
被打断，这消除了中断处理的开销。
-
中断合并 https://en.wikipedia.org/wiki/Interrupt_coalescing - 使用硬件中断，但如果发生中断，则禁用中断并启动poll http://en.wikipedia.org/wiki/Polling_(computer_science)，持续一段时间，之后轮询终止并激活中断。
https://en.wikipedia.org/wiki/Interrupt_coalescing https://en.wikipedia.org/wiki/Interrupt_coalescing中的一项技术
哪些事件通常会触发硬件中断是
忍住， 任何一个直到达到一定数量工作待处理，或
超时定时器触发。
这两种方法都没有显着的中断成本——这是默认中断驱动模式之前的优势。
但第二种方法——中断合并更为理性，因为：
IRQ 合并之前 NAPI 有哪些优点？
我将 NAPI 视为中断合并的一种形式。我认为你的问题可能源于对NAPI的误解。首先，NAPI涉及到中断。而且，NAPI的民意调查其实也不是“白费”。请记住，对于 NAPI，其理念是高吞吐量流量是突发性的。 NAPI 仅在“数据包接收中断”发生后“启动”。
以下是如何使用 NAPI 的快速概述：
内核启动“数据包接收”中断，使用 NAPI 的网络设备驱动程序会检测到该中断。然后是网络设备驱动程序禁用与接收数据包相关的中断并使用 NAPI 告诉 Linux 网络子系统轮询设备驱动程序。 poll 函数由设备驱动程序实现，并传递给网络子系统，并包含设备驱动程序的数据包处理程序。在接收到足够的数据包或达到超时后，重新启用数据包接收中断，一切重新开始。
因此，NAPI 基本上只是 Linux 网络子系统中的一个集中式 API，用于支持中断合并以减少接收活锁情况。 NAPI 为设备驱动程序开发人员提供了一个干净的中断合并框架。 NAPI 并不是一直运行，而是仅在实际接收到流量时才发生，这使得它本质上是一种中断合并方案……至少在我的书中是这样。
Note：这都是在使用 NAPI 的网络设备驱动程序的上下文中，但实际上 NAPI 可以用于任何类型的中断。这也是 NAPI 的好处之一。
如果我的理解有什么错误，欢迎指出！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
