1、测试拓扑:
host->nic->nic->ovs-vm
host和运行ovs的设备不是同一台设备!mtu默认为网卡的,默认的是1500,网卡为intel 82599 万兆卡
2、测试结果
下图解释
左:iperf3 客户端发送数据
中:ovs数据统计
右:VM数据统计
iperf3命令:host运行客户端iperf3 -c 192.168.10.2 -i 1 -t 10, vm里运行服务器端iperf3 -s -i 1
图1:原生ovs,iperf3测试的结果是平均9个G的流量
VM里的数据
数据包统计(个)
host | ovs-物理口网卡 | ovs-tapt口 | vm-eth0 | |
发送 | 6481244 | 145192 | 195417 | 145274 |
接收 | 145094 | 6481246 | 145165 | 195373 |
流量统计(字节)
host | ovs-物理网卡 | ovs-tap口 | vm-eth0 | |
发送 | 9812536474 | 9632445 | 9397678252 | 9631212 |
接收 | 9620266 | 9812537062 | 9621352 | 9397674572 |
结论:host发送和接收的数据和ovs的物理网卡数据基本吻合,但ovs的物理网卡的接收数据和ovs的tapt口的发送数据包不吻合,差距还有点大,
但根据流量统计表可以看出,流量是吻合的,说明ovs物理网卡到tap口对tcp数据包做了优化,数据包变少,但流量没有变化,原因在于ovs添加的tap口支持tso功能。
查看网卡tso功能命令;ethtool -k tap1
tcp-segmentation-offload: on
假如关掉tap设备的tso功能,iperf3测试的结果和ovs+dpdk测试的结果基本一致了
图2:ovs+dpdk,iperf3测试的结果平均6个G
数据包统计(个)
host | ovs-dpdk口 | ovs-vhostuser口 | vm-eth0 | |
发送 | 3621621 | 1745737 | 3620306 | 1745732 |
接收 | 1745697 | 3621621 | 1745728 | 3620307 |
流量统计(字节)
host | ovs-dpdk口 | ovs-vhostuser口 | vm-eth0 | |
发送 | 5483063231 | 115399172 | 5481073901 | 115396274 |
接收 | 115396436 | 5483063297 | 115396148 | 5481073901 |
结论:发送的数据包和流量在每个接口基本吻合,但在ovs的dpdk口转向ovs的vhostuser口时,数据drop了1321个,
vhostuser支持tso,原理就是欺骗VM,让VM发64k打包,然后交给物理网卡分包
从iperf流量统计看,原生ovs流量9个G明显大于ovs+dpdk的6个G,但会发现一个问题,就是ovs+dpdk的dpdk口到vhostuser的数据包是3620306个,而原生ovs的物理网卡到tap设备的数据包只有195417个,所以ovs+dpdk的数据包处理能力肯定是大于原生ovs的,但ovs+dpdk的vhostuser接口不支持tso,导致iperf3测试结果不理想
原因分析:网卡默认是打开gro关闭lro的,所以在测试原生ovs时,网卡会将多个数据包合并成一个数据包再交给内核协议栈,tap设备收到的数据包数会很小,而用ovs+dpdk时,网卡并没有合成数据包(网卡没合成数据包原因待分析),vhostuser收到的数据包个数就是对方发送的数据个数,造成vm 处理不过来,vhostuser丢包。
测试结果可以证明原生ovs使用内核驱动网卡在收取数据包做GRO/LRO时,没有计算合并后数据包的tcp校验和只是设置了标志位告诉上层这个合并数据包可用。