linux - 在IRQ合并之前，NAPI有哪些优势？

众所周知，有两种方法可以避免高负载网络中某些硬件中断的开销，当硬件中断太多时，切换到它们会花费太多时间。这对于性能和程序风格的选择方法非常重要。

NAPI (New API)-每隔一定时间不使用硬件中断和polls以太网设备。 Linux内核默认使用中断驱动模式，并且仅在传入数据包的流量超过特定阈值时才切换到轮询模式。

Interrupt coalescing-使用硬件中断，但是如果发生中断，则在一定时间段内禁用该中断并启动poll，然后终止轮询并激活该中断。

两种方法都没有显着的中断成本-这是默认中断驱动模式的优势。

但是第二种方法-中断合并更为合理，因为它:

较小的延迟-程序包到达后，立即尝试立即处理它，或者在最近发生中断时立即对其进行轮询。相反的NAPI不会立即处理该帧，但将等待一段时间以进行下一次轮询。

减少CPU使用率-仅当至少一个数据包已经到达时才开始轮询。但是，即使没有收到帧，也没有白费力气，就像执行NAPI一样。

在IRQ合并之前，NAPI有哪些优势？

最佳答案

我将NAPI视为中断合并的一种形式。我认为您的问题可能源于对NAPI的误解。首先，NAPI涉及到中断。而且，NAPI的轮询实际上不是“徒劳的”。请记住，对于NAPI，想法是高吞吐量的流量是突发性的。 NAPI仅在“数据包接收到中断”发生后才“启动”。

这是应该如何使用NAPI的快速概述:

内核启动“已收到数据包”中断，使用NAPI的网络设备驱动程序会检测到该中断。然后，网络设备驱动程序禁用与接收数据包和使用NAPI相关的中断，告诉Linux网络子系统轮询设备驱动程序。轮询功能由设备驱动程序实现，并传递给网络子系统，并包含设备驱动程序的数据包处理程序。接收到足够的数据包或达到超时后，将重新启用数据包接收中断，然后一切重新开始。

因此，NAPI基本上只是Linux网络子系统中的集中式API，用于支持中断合并以减少接收事件锁的情况。 NAPI为设备驱动程序开发人员提供了一个干净的框架，用于中断合并。 NAPI并非一直运行，而是仅在实际接收到流量时才发生，从而使其本质上是一种中断合并方案……至少在我的书中。

注意:所有这些都是在使用NAPI的网络设备驱动程序的上下文中进行的，但实际上NAPI可以用于任何类型的中断。这也是NAPI的好处之一。

如果我的理解有任何错误，请随时指出!

关于linux - 在IRQ合并之前，NAPI有哪些优势？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/28090086/