平定igb之“乱”
2016-01-12 17:41
295 查看
作者:dnk_admin 发布:2012-06-04 21:50 分类:开发经验, 软件使用经验
继《tcpdump之“乱”象? | DNK的博客》===>
我作了下述实验:
Dell 2850(as5.5) + e1000, tcpdump无乱序;
Dell 2950(as5.5) + bnx2,tcpdump无乱序;
Dell R720(centos6.2) + igb, tcpdump乱序。
呵呵,同样是千兆的网卡,igb的表现出位啊。
当前系统使用igb驱动的网卡设备名是em3;CPU逻辑核数是24个。
cat /proc/interrupts | grep em3, 从结果可以分析出,em3共申请了24个rx队列与24个tx队列。
每个rx队列,中断数量几乎一致,应该是被均摊到各个CPU逻辑核;由于是作抓包功能,tx队列几乎没有产生什么中断。
查看/sys/class/net/em3/queue/目录,其下有rx-[0…23]、tx-[0…23]共48个文件。
看来,igb为每个设备申请了每CPU独占的队列,抓包时,可以从报文到达网卡开始就进行高度并行的中断处理。
也正是因为高度并发的每CPU[硬中断->rx队列->软中断]机制,使得tcpdump抓到的报文顺序看起来是乱的。
为了验证以上分析,特地修改了igb的驱动代码,将每个设备申请的rx队列与tx队列调整为1;
调整方法是:将igb.h里IGB_MAX_RX_QUEUES、IGB_ABS_MAX_TX_QUEUES、IGB_MAX_TX_QUEUES三个宏的値全部改为1。
奇怪的是,tcpdump现在不乱序了,但是表现为丢包。
继续折腾折腾,在igb的驱动代码里看到gro相关的东西:igb_main.c的igb_clean_rx_irq_adv函数,多个数据包通过skb_fill_page_desc接口追加到一起。
记得我以前在小改协议栈的时候,看过一段gro相关的代码;拜访了google,更具体的了解到,一些高级网卡为了提升网络的影响时间与呑吐量,支持gso/tso/ufo/gro之类的功能。
经过评估,很可能就是这个gro机制,使得某些相关联的报文“粘”成一个,所以表现出丢包。
通过ethtool -K em3 gro off,将网卡的gro功能关闭,再测试,tcpdump抓包的时候,终于不乱序也不丢包了。
至此,终于平定了igb之“乱”;也为tcpdump平反,严格来说,乱序不是tcpdump引起的。
至于《tcpdump之“乱”象? | DNK的博客》提及的ixgb之“乱”,经过初步评估(中断分布、队列分布),判断其与igb属相同性质,后续有时间再来研究把玩论证啰。
——————————————————————————————————————
末了,杀个回马枪,如果只关闭igb的gro,而不将限定rx队列与tx队列为1的话,tcpdump抓包还是乱序的。
其实,平定igb之“乱”的方法,在保证tcpdump抓包功能表现正常之余,它的最大弊端就是,将提升性能的精髓部分抹掉了,这在非常关注网络性能的场合,万万使不得的,除非论证后抓包性能不是瓶颈;本文所述的方法,纯粹只是研究把玩一下。
话说,人家bnx2及e1000也千兆的,倒是挺中规中矩,没有使用每CPU[硬中断+队列+软中断]的高深玩意;不过三者的性能倒是没有作过对比。理论上,igb可能更胜一筹。
本文固定链接: http://www.danoking.com/2012/06/04/%e5%b9%b3%e5%ae%9aigb%e4%b9%8b%e4%b9%b1/ | DNK的博客
该日志由 dnk_admin 于2012年06月04日发表在 开发经验, 软件使用经验 分类下, 你可以发表评论,并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: 平定igb之“乱” | DNK的博客
继《tcpdump之“乱”象? | DNK的博客》===>
我作了下述实验:
Dell 2850(as5.5) + e1000, tcpdump无乱序;
Dell 2950(as5.5) + bnx2,tcpdump无乱序;
Dell R720(centos6.2) + igb, tcpdump乱序。
呵呵,同样是千兆的网卡,igb的表现出位啊。
当前系统使用igb驱动的网卡设备名是em3;CPU逻辑核数是24个。
cat /proc/interrupts | grep em3, 从结果可以分析出,em3共申请了24个rx队列与24个tx队列。
每个rx队列,中断数量几乎一致,应该是被均摊到各个CPU逻辑核;由于是作抓包功能,tx队列几乎没有产生什么中断。
查看/sys/class/net/em3/queue/目录,其下有rx-[0…23]、tx-[0…23]共48个文件。
看来,igb为每个设备申请了每CPU独占的队列,抓包时,可以从报文到达网卡开始就进行高度并行的中断处理。
也正是因为高度并发的每CPU[硬中断->rx队列->软中断]机制,使得tcpdump抓到的报文顺序看起来是乱的。
为了验证以上分析,特地修改了igb的驱动代码,将每个设备申请的rx队列与tx队列调整为1;
调整方法是:将igb.h里IGB_MAX_RX_QUEUES、IGB_ABS_MAX_TX_QUEUES、IGB_MAX_TX_QUEUES三个宏的値全部改为1。
奇怪的是,tcpdump现在不乱序了,但是表现为丢包。
继续折腾折腾,在igb的驱动代码里看到gro相关的东西:igb_main.c的igb_clean_rx_irq_adv函数,多个数据包通过skb_fill_page_desc接口追加到一起。
记得我以前在小改协议栈的时候,看过一段gro相关的代码;拜访了google,更具体的了解到,一些高级网卡为了提升网络的影响时间与呑吐量,支持gso/tso/ufo/gro之类的功能。
经过评估,很可能就是这个gro机制,使得某些相关联的报文“粘”成一个,所以表现出丢包。
通过ethtool -K em3 gro off,将网卡的gro功能关闭,再测试,tcpdump抓包的时候,终于不乱序也不丢包了。
至此,终于平定了igb之“乱”;也为tcpdump平反,严格来说,乱序不是tcpdump引起的。
至于《tcpdump之“乱”象? | DNK的博客》提及的ixgb之“乱”,经过初步评估(中断分布、队列分布),判断其与igb属相同性质,后续有时间再来研究把玩论证啰。
——————————————————————————————————————
末了,杀个回马枪,如果只关闭igb的gro,而不将限定rx队列与tx队列为1的话,tcpdump抓包还是乱序的。
其实,平定igb之“乱”的方法,在保证tcpdump抓包功能表现正常之余,它的最大弊端就是,将提升性能的精髓部分抹掉了,这在非常关注网络性能的场合,万万使不得的,除非论证后抓包性能不是瓶颈;本文所述的方法,纯粹只是研究把玩一下。
话说,人家bnx2及e1000也千兆的,倒是挺中规中矩,没有使用每CPU[硬中断+队列+软中断]的高深玩意;不过三者的性能倒是没有作过对比。理论上,igb可能更胜一筹。
本文固定链接: http://www.danoking.com/2012/06/04/%e5%b9%b3%e5%ae%9aigb%e4%b9%8b%e4%b9%b1/ | DNK的博客
该日志由 dnk_admin 于2012年06月04日发表在 开发经验, 软件使用经验 分类下, 你可以发表评论,并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: 平定igb之“乱” | DNK的博客
相关文章推荐
- IIS Handler and Module探索
- ubuntu14.04无法连接有线连接问题
- 1.3线程停止
- AlertDialog的create和show
- 动态添加综合布局---动态添加控件及将某XML动态加入到Activity显示(续)
- JS函数集合大全
- Unity3D中的Coroutine详解
- [转帖]fstream的使用方法介绍
- 新春赏花看梯田-罗平元阳东川红土红摄影
- ssh通道技术
- ajax处理返回的json格式数据
- 故障案例:一个子查询导致服务崩溃
- 动态添加控件及将某XML动态加入到Activity显示
- web日志分析
- ECharts3.0 强大的统计图
- Iphone的私有API
- OPENCV常见错误(一)
- Android启动另一个APP时,注意disable与enable的问题
- 使用Git上传本地项目代码到github
- R 绘图 填充颜色