> Adaptive-rx / Adaptive-tx,和
> NAPI;
我希望得到一个答案,解释更接近Linux内核源代码级别的差异？另外,我想听听如何在大约400Mbps的负载下强制NIC轮询/中断合并模式.
更多背景：
问题似乎是bnx2和e1000驱动程序忽略“ethtool -C adaptive-rx on”命令.这可能是因为这些驱动程序不支持自适应中断.虽然Broadcom Programmer的参考手册说BCM5709 NIC硬件应支持此功能.
所以我决定尝试NAPI并在netif_napi_add()函数调用中将权重从64减少到16,以便在低得多的负载下强制NIC处于轮询模式,但不幸的是,这没有成功.我想NAPI在NIC中不需要任何特殊的硬件支持,这是正确的吗？
我使用的硬件是BCM5709 NIC(它使用bnx2驱动程序). OS是Ubuntu 10.04. cpu是XEON 5620.
解决方法
>收到X帧后产生中断(ethtool中的rx帧)
>在X usecs之后不再接收到帧时生成中断(ethtool中的rx-usecs)
使用这些硬件方法的问题是您需要选择它们来优化吞吐量或延迟,您不能同时拥有这两者.为每个接收帧生成一个中断(rx-frames = 1)可以最大限度地减少延迟,但就中断服务开销而言,这样做成本很高.设置一个较大的值(比如rx-frames = 10)可以减少因接收到的每十帧只产生一个中断所消耗的cpu周期数,但是对于该十个组中的第一帧,您也会遇到更高的延迟.
NAPI实现尝试利用流量串联的事实,以便在收到的第一帧上立即生成中断,然后立即切换到轮询模式(即禁用中断),因为更多的流量将紧随其后.在轮询了一定数量的帧(问题中为16或64)或某个时间间隔后,驱动程序将重新启用中断并重新开始.
如果您有可预测的工作负载,则可以为上述任何一个(NAPI,rx-frames,rx-usecs)选择固定值,这些值可以为您提供正确的权衡,但大多数工作负载会有所不同,您最终会做出一些牺牲.这就是adaptive -vx / adaptive-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？等)对延迟的敏感性.
戴夫
