服务器网卡收包性能测试

之前写过不少跟网络相关的 benchmark,比如:
* 《网络质量评估
* 《10G(82599EB) 网卡测试优化(总)

上面的更多的是放在带宽使用率上,即如何尽可能的打满,但是都遗漏一个重要的细节,那就是 packet/s,这个论坛的作者一语中的:
– how many packets/sec you have. In fact, network throughput mostly depends on packets/sec, not bytes/sec

可能对于大部分的应用来说,根本无需关注每秒钟到达的包的数量甚至大小,但是对于某些应用来说,这些指标是至关重要的。

要对包(大小、数量、时间)方面的指标做 benchmark,iperf, netperf 之类的就没法用了,他们只能测试带宽,经过一天的使用比较发现下面的一些工具能基本满足需求。要快速的上手的话还是需要对 tcp/ip 有比较深入的了解,比如 ip header,tcp header 之类的,再比如最小的 frame 应该是 64B,这也是众多网络设备厂商做包转发测试的基础,不明白的看下面两张(1, 2)图就清楚了。

跟网络厂商一样,我们也重点关注小包(0-75)的性能,至于小包如何定义,没有严格的标注,我上面的 0-75 也仅仅是从 iptraf 拿到的一个范围,最终还是要根据业务来定。
一般而言,frame(fps) 是针对 data-link(Ethernet) 而言,packet(pps) 是针对 IP 层而言,segment 是针对 TCP 层而言。

nping
基本的功能还是不错的,但是发包能力相对弱了些,试了几种方式,比如下面这个根本达不到 500K/s 的要求,实际也就 150K/s 左右,记得加上 -N/-H,这样速度能提高几个数量级别:
# nping –tcp 192.168.50.52 –rate 500000 -c 500000000 -N -H

三个使用方式:
1. cheatsheet
2. ARP 的 MIT 还是很方便的
3. 常用方法


hping3
基本功能跟 nping 类似,tcp, udp, icmp, arp 都可以伪造篡改,但是发包的效率比上面好的多。
我发送 60B 的小包(40B head + 20B data),–fast/–faster/–flood 三种不同的类型分别能达到 20 rxpck/s, ~130K rxpck/s, 260K rxpck/s,并且在 –flood 状态,tcp, interrupts 基本饱和:
# hping3 -c 100000000 -d 20 -S -p 80 –fast/–faster/–flood  192.168.50.52 –rand-source

使用:
1. cheatsheet
2. dos using hping3 with spoofed ip in kali linux


pktgen
直接 modpore 往 /proc/net/pktgen/ 里面填 tcp/ip 的选项就好了,操作蛮简单的,可以看下面几篇文档:
* 《pktgen linuxfoundation
* 《pktgen
* 《How do I stress test my local network using pktgen?》  
总的来说,这个工具不管是带宽还是发包速率都不是很好控制,一旦启动就直接打满。


packETH
这是目前用的最满意的一个,分为 gui、cli 两种,cli 的功能不全面,gui 的可以根据带宽、包的大小来做 benchmark。测试服务器通过 X11 forwarding 就可以打开界面了。

关于 GUI 的使用方法,可以看这里:
* http://packeth.sourceforge.net/packeth/GUI_version.html
* http://www.kuncar.net/blog/packeth-tutorial-part-i-the-inetrface-and-the-packet-builder/2013/
* http://www.kuncar.net/blog/packeth-tutorial-part-ii-the-gen-bgen-s-and-pcap-options/2013/

这里我做了一个快速的分别是针对 60B, 150B, 1400B 的包,随机 src MAC、src IP,在尽可能利用带宽的情况下的 benchmark。这个 gist 记录的是 rx_discard 每秒的丢包结果。
用到的工具,观察的现象也很朴素,如下:
while true; do  echo "—- $(date +'%H:%M:%S')" ;R1=$(ethtool  -S em1 | grep rx_dis | cut -d":" -f 2) ;sleep 1;R2=$(ethtool  -S em1 | grep rx_dis| cut -d ":" -f 2); R=`expr $R2 – $R1`; echo $R  ; done;
上面这个是计算每秒 drop 的数量,下面这些是一些不同层面的监控对比:
* sar -n DEV 1 | grep bond0
* iptraf
* ibmonitor
* mpstat -P ALL 1

简要说下结果。小包对系统资源的消耗是非常明显的,这也是无数的公司都花了大量的时间在提升小包处理的效率上。
对于 60B 的小包,系统只能打到 300M,600Kpps/s,rx_discards/s 非常大。
150B 的包,能打到 700M,600Kpps/s,rx_discard/s 同样严重。
1400B 的包,能打到 1800M(两条千兆 bonding),pps 下降到了 200K,rx_discard 要好的多。
600B  以上的包的情况大为好转,基本都能打到 1800M,同时 rx_discards 明显小很多。

这里有使用 packETH 做的 40G benchmark。

Ostinato
跟 packETH 类似,对于各种协议的包的组合非常灵活,可以生成很多非标准的包,比如 IP over IP, ARP over TCP 等等,文档写的很清楚,上手很快。比较麻烦的是是需要在被 benchmark 的机器部署同样的包,跟 iometer 有点类似,而 packETH 则是 standalone 的。

再介绍两个工具,一个叫 scapy;一个叫 netsniff-ng(1, 2) ,后者有集大成的架势,这里是他的使用文档,因为太全面了,是一个综合性的工具,反而没有专心把一件事做好的工具更精致。


上面的工具还不够胃口?看这里(1, 2)。依然不满意?直接上专业硬件线速发包工具吧,1G、10G、40G 已经没意思了,直接上 400G 的吧。

  • innoink

    pktgen-dpdk 一直用这个