谁能解释在高网络负载下如何使用以下两种技术来减轻中断开销？
我希望得到一个能解释接近Linux内核源代码级别差异的答案？我也想听听如何在负载约为400Mbps时强制NIC进入轮询/中断合并模式。
更多背景：
问题似乎是bnx2和e1000驱动程序忽略了“ ethtool -Cadaptive-rx on”命令。这可能是因为这些驱动程序不支持自适应中断。尽管Broadcom程序员参考手册说BCM5709 NIC硬件应支持此功能。
因此，我决定尝试使用NAPI并将netif_napi_add（）函数调用中的权重从64降低到16，以强制NIC在轮询模式下以低得多的负载运行，但是不幸的是，这种方法无法解决。我猜想NAPI在NIC中不需要任何特殊的硬件支持，对吗？
我使用的硬件是BCM5709 NIC（它使用bnx2驱动程序）。操作系统是Ubuntu 10.04。CPU是XEON 5620。
Answers:
中断缓和的主要原理是每个接收帧生成少于一个中断（或每个发送帧完成生成一个中断），从而减少了服务中断时遇到的OS开销。BCM5709控制器在硬件中支持多种方法来合并中断，包括：
使用这些硬件方法的问题在于，您需要选择它们以优化吞吐量或延迟，而不能同时使用它们。为每个接收到的帧（rx-frames = 1）生成一个中断可以最大程度地减少延迟，但是这样做会在中断服务开销方面付出高昂的代价。设置较大的值（例如rx-frames = 10）可以减少接收CPU周期的次数，因为每接收十个帧仅生成一个中断，但是对于十个一组的前几帧，您也会遇到更高的延迟。
NAPI实现尝试利用流量成束出现的事实，以便您在接收到的第一个帧上立即生成一个中断，然后立即切换到轮询模式（即禁用中断），因为后面将有更多流量通过。在轮询了一定数量的帧（问题中为16或64）或某个时间间隔后，驱动程序将重新启用中断并重新开始。
如果您具有可预测的工作量，则可以为上述任何一个（NAPI，rx-frames，rx-usecs）选择固定值，这些值可以为您提供适当的权衡，但是大多数工作量会有所不同，最终您会付出一些牺牲。这就是自适应rx /自适应tx发挥作用的地方。想法是，驱动程序不断监视工作负载（每秒接收的帧，帧大小等），并调整硬件中断合并方案，以在低流量情况下优化延迟，或在高流量情况下优化吞吐量。这是一个很酷的理论，但是在实践中可能很难实现。只有少数驱动程序实现了它（请参阅http://fxr.watson.org/fxr/search?v=linux-2.6&string=use_adaptive_rx_coalesce），而bnx2 / e1000驱动程序不在该列表中。
为了更好地描述每个ethtool合并字段应该如何工作，请在以下地址查看ethtool_coalesce结构的定义：
http://fxr.watson.org/fxr/source/include/linux/ethtool.h?v=linux-2.6#L111
对于您的特定情况（吞吐量约为400Mb / s），建议您调整rx-frames和rx-usecs值，以获得适合您的工作负载的最佳设置。查看ISR的开销以及应用程序（httpd？等）对延迟的敏感性。
戴夫