NAPI与自适应中断

任何人都可以请解释如何使用两个以下的技术来缓解高networking负载下的中断开销?

  1. Adaptive-rx / Adaptive-tx和
  2. NAPI;

我将不胜感激解释接近Linux内核源代码级别的差异? 另外我想听听如何强制networking轮询/中断合并模式在400Mbps的负载。

更多背景:

这个问题似乎是,bnx2和e1000驱动忽略了“ethtool -C adaptive-rx on”命令。 这可能是因为这些驱动程序不支持自适应中断。 虽然Broadcom Programmer的参考手册中提到BCM5709 NIC硬件应支持此function。

所以我决定尝试NAPI,并在netif_napi_add()函数调用中将权重从64减less到16,以便在低得多的负载下强制NIC在轮询模式下,但不幸的是,这并没有奏效。 我想NAPI不需要在NIC中有任何特殊的硬件支持,对吗?

我使用的硬件是BCM5709网卡(它使用bnx2驱动程序)。 而操作系统是Ubuntu 10.04。 CPU是XEON 5620。

中断调节的主要原理是每个接收帧产生less于一个的中断(或每个发送帧完成一个中断),减less了维护中断时遇到的操作系统开销。 BCM5709控制器在硬件上支持一些合并中断的方法,包括:

  • 在收到X帧(ethtool中的rx帧)后生成中断
  • 在X usecs之后没有收到更多帧时产生一个中断(ethtool中的rx-usecs)

使用这些硬件方法的问题是您需要select它们来优化吞吐量或延迟,您不能同时使用这两种方法。 为每个接收到的帧生成一个中断(rx-frame = 1)可以最大限度地减less延迟,但是在中断服务开销方面它的成本很高。 设置一个较大的值(比如rx-frames = 10)可以减less接收到的每十个帧只产生一个中断所消耗的CPU周期数,但是对于这个十个组中的第一帧也会遇到更高的延迟。

NAPI的实现尝试利用stream量集中的事实,以便在收到第一帧时立即生成中断,然后立即切换到轮询模式(即禁用中断),因为更多的stream量将被closures。 在轮询一定数量的帧(问题中的16或64)或某个时间间隔后,驱动程序将重新启用中断并重新开始。

如果您有一个可预测的工作负载,那么可以为上述任何一个选项(NAPI,rx-frame,rx-usecs)select固定值,这样可以为您提供合适的权衡,但是大多数工作负载会有所不同,您最终会做出一些牺牲。 这就是adaptive-rx / adaptive-tx发挥作用的地方。 这个想法是,驾驶员不断监测工作量(每秒接收的帧数,帧大小等),并调整硬件中断合并scheme,优化低stream量情况下的延迟或优化高stream量情况下的吞吐量。 这是一个很酷的理论,但在实践中可能很难实施。 只有less数驱动程序实现它(请参阅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的吞吐量),我build议你调整rx-frame和rx-use的值,以获得最佳的工作负载设置。 看看ISR的开销以及应用程序(httpd?等)对延迟的敏感度。

戴夫