本文共 1570 字，大约阅读时间需要 5 分钟。

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校验和只是设置了标志位告诉上层这个合并数据包可用。