NAPI 中断禁用和处理共享中断线
NAPI interrupt disabling and handling shared interrupt line
我正在尝试了解 linux 内核中的 NAPI 实现。以上是我的基本疑惑。
1) NAPI 禁用进一步中断并使用轮询处理 skbs'
- 谁禁用了它？
中断处理程序是否应该禁用它？
如果是 - 禁用中断和处理 SOFTIRQ 之间的时间间隔是不是 net_rx_action 实际完成轮询的地方太多了。
2) 默认情况下，所有启用 NAPI 的驱动程序在接收到单个帧时会禁用中断并在下半部分使用轮询处理剩余帧？
还是只有当帧数 > 32（在 irq 处理程序中连续接收所有帧）时才切换到轮询模式？
3) 现在共享 IRQ -
- 其他设备中断会发生什么情况，其他设备的下半部分可能不会 运行 因为这些设备不在 poll_list.
中
我写了一份综合指南 understanding, tuning, and optimizing the Linux network stack，其中解释了有关网络驱动程序、NAPI 等的所有内容，所以请查看。
就您的问题而言：
设备 IRQ 应该在启用 NAPI 后由驱动程序的 IRQ 处理程序禁用。是的，有时间间隔，但应该很小。这是您必须做出的权衡决定的一部分：您更关心吞吐量还是延迟？根据具体情况，您可以适当优化网络堆栈。在任何情况下，大多数 NIC 都允许用户增加（或减少）用于跟踪传入网络数据的环形缓冲区的大小。因此，暂停是可以的，因为数据包只会排队等待稍后处理。
这取决于驱动程序，但通常大多数驱动程序都会在 IRQ 处理程序中启用 NAPI 轮询模式，一旦它被触发（通常）调用 napi_schedule。您可以找到如何 NAPI is enabled for the Intel igb driver here. Note that IRQ handlers are not necessarily fired for every single packet. You can adjust the rate at which IRQ handlers fire on most cards by using a feature called interrupt coalescing 的演练。某些 NIC 可能不支持此选项。
其他设备的 IRQ 处理程序将在 IRQ 触发时执行，因为 IRQ 处理程序在 CPU 上具有非常高的优先级。 NAPI 轮询循环（在 SoftIRQ 中 运行s）将 运行 在处理设备 IRQ 的任何 CPU 上。因此，如果您有多个 NIC 和多个 CPU，您可以调整每个 NIC 的 IRQ 的 IRQ 亲和力，以防止特定 NIC 饿死。
关于你在评论中问到的例子：
say NIC 1 and NIC 2 share IRQ line , lets assume NIC 1 is low load , NIC 2 high load and NIC 1 receives interrupt, driver of NIC 1 would disable interrupt until it's softirq is handled , say that time gap as t1 . So for time t1 NIC 2 interrupts are too disabled, right?
这取决于驱动程序，但在正常情况下，NIC 1 仅在执行 IRQ 处理程序时禁用中断。对 napi_schedule 的调用告诉 softirq 代码它应该开始 运行ning 如果它还没有开始。 softirq 代码 运行s 是异步的，所以没有 NIC 1 不等待 softirq 被处理。
现在，就共享 IRQ 而言：它又取决于设备和驱动程序。驱动程序应该以能够处理共享 IRQ 的方式编写。如果驱动程序禁用正在共享的 IRQ，则共享该 IRQ 的所有设备都不会接收中断。这会很糟糕。某些设备解决此问题的一种方法是允许驱动程序 read/write 到特定寄存器，从而导致该特定设备停止生成中断。这是首选解决方案，因为它不会阻止其他设备生成相同的 IRQ。
当 NAPI 的 IRQ 被禁用时，这意味着驱动程序要求 NIC 硬件停止发送 IRQ。因此，同一行（对于其他设备）上的其他 IRQ 仍将继续处理。下面是 Intel igb driver 如何通过写入寄存器来关闭该设备的 IRQ 的示例。
我正在尝试了解 linux 内核中的 NAPI 实现。以上是我的基本疑惑。
1) NAPI 禁用进一步中断并使用轮询处理 skbs'
- 谁禁用了它？
中断处理程序是否应该禁用它？
如果是 - 禁用中断和处理 SOFTIRQ 之间的时间间隔是不是 net_rx_action 实际完成轮询的地方太多了。
2) 默认情况下，所有启用 NAPI 的驱动程序在接收到单个帧时会禁用中断并在下半部分使用轮询处理剩余帧？ 还是只有当帧数 > 32（在 irq 处理程序中连续接收所有帧）时才切换到轮询模式？
3) 现在共享 IRQ -
- 其他设备中断会发生什么情况，其他设备的下半部分可能不会 运行 因为这些设备不在 poll_list. 中
我写了一份综合指南 understanding, tuning, and optimizing the Linux network stack，其中解释了有关网络驱动程序、NAPI 等的所有内容，所以请查看。
就您的问题而言：
设备 IRQ 应该在启用 NAPI 后由驱动程序的 IRQ 处理程序禁用。是的，有时间间隔，但应该很小。这是您必须做出的权衡决定的一部分：您更关心吞吐量还是延迟？根据具体情况，您可以适当优化网络堆栈。在任何情况下，大多数 NIC 都允许用户增加（或减少）用于跟踪传入网络数据的环形缓冲区的大小。因此，暂停是可以的，因为数据包只会排队等待稍后处理。
这取决于驱动程序，但通常大多数驱动程序都会在 IRQ 处理程序中启用 NAPI 轮询模式，一旦它被触发（通常）调用
napi_schedule。您可以找到如何 NAPI is enabled for the Intel igb driver here. Note that IRQ handlers are not necessarily fired for every single packet. You can adjust the rate at which IRQ handlers fire on most cards by using a feature called interrupt coalescing 的演练。某些 NIC 可能不支持此选项。其他设备的 IRQ 处理程序将在 IRQ 触发时执行，因为 IRQ 处理程序在 CPU 上具有非常高的优先级。 NAPI 轮询循环（在 SoftIRQ 中 运行s）将 运行 在处理设备 IRQ 的任何 CPU 上。因此，如果您有多个 NIC 和多个 CPU，您可以调整每个 NIC 的 IRQ 的 IRQ 亲和力，以防止特定 NIC 饿死。
关于你在评论中问到的例子：
say NIC 1 and NIC 2 share IRQ line , lets assume NIC 1 is low load , NIC 2 high load and NIC 1 receives interrupt, driver of NIC 1 would disable interrupt until it's softirq is handled , say that time gap as t1 . So for time t1 NIC 2 interrupts are too disabled, right?
这取决于驱动程序，但在正常情况下，NIC 1 仅在执行 IRQ 处理程序时禁用中断。对 napi_schedule 的调用告诉 softirq 代码它应该开始 运行ning 如果它还没有开始。 softirq 代码 运行s 是异步的，所以没有 NIC 1 不等待 softirq 被处理。
现在，就共享 IRQ 而言：它又取决于设备和驱动程序。驱动程序应该以能够处理共享 IRQ 的方式编写。如果驱动程序禁用正在共享的 IRQ，则共享该 IRQ 的所有设备都不会接收中断。这会很糟糕。某些设备解决此问题的一种方法是允许驱动程序 read/write 到特定寄存器，从而导致该特定设备停止生成中断。这是首选解决方案，因为它不会阻止其他设备生成相同的 IRQ。
当 NAPI 的 IRQ 被禁用时，这意味着驱动程序要求 NIC 硬件停止发送 IRQ。因此，同一行（对于其他设备）上的其他 IRQ 仍将继续处理。下面是 Intel igb driver 如何通过写入寄存器来关闭该设备的 IRQ 的示例。