On 10/27/21 17:48, Mike Pattrick wrote: > Currently the ovs-tcpdump utility creates a virtual tunnel to send > packets to. This method functions perfectly fine, however, it can > greatly impact performance of the monitored port. > > It has been reported to reduce packet throughput significantly. I was > able to reproduce a reduction in throughput of up 70 percent in some > tests with a simple setup of two hosts communicating through a single > bridge on Linux with the kernel module datapath. Another more complex > test was configured for DPDK and the usermode datapath. This test > involved a data path going from a VM, through a port into one OVS > bridge, out through a network card which could be DPDK enabled for the > relevant tests, in to a different network interface, then into a > different OVS bridge, through another port, and then into a virtual > machine. > > Using the dummy driver resulted in the following impact to performance > compared to no ovs-tcpdump. Due to intra-test variance and fluctuations > during the first few seconds after installing a tap; multiple samples > were taken over multiple test runs. The first few seconds worth of > results were discarded and then results were averaged out. > > Original Script > =============== > Category Impact on Throughput > Kernel datapath - 65% > Usermode datapath - 26% > DPDK datapath - 37% > > New Script > ========== > Category Impact on Throughput > Kernel datapath - 5% > Usermode datapath - 16% > DPDK datapath - 29% > > Signed-off-by: Mike Pattrick <m...@redhat.com> > --- > utilities/ovs-tcpdump.in | 42 +++++++++++++++++++++------------------- > 1 file changed, 22 insertions(+), 20 deletions(-) >
Hi, Mike. Thanks for working on this! I didn't test myself, but numbers in the commit message looks impressive. The performance impact on kernel datapath surprised me though. Do you know why there is so big difference? I'd expect this kind of performance drop for userspace datapath, but not for a kernel. One comment to the commit message is: Please don't use the term 'DPDK datapath'. There is no such thing. It's userspace datapath with dpdk ports. Usage of the 'DPDK datapth' term creates a lot of confusion for users. And for the implementation: 'dummy' module is mostly used for kernel testing and it's not typically loaded by default on various systems (I don't have it loaded on any of my systems). So, IIUC, ovs-tcpdump will fail by default. At least we should print some meaningful error message in this case. Another option is to emit a warning and fall back to usual tap interface. What do you think? Aaron? Gaetan? It's also a bit weird that code uses 'tap' in the names of variables, but not a big deal, I guess. Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
