On Wed, 2021-11-03 at 16:53 +0100, Ilya Maximets wrote: > 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.
I didn't investigate this thoroughly, just reproduced it a few times on different distributions. If there's some interest I could deep dive into this. > 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. Noted, I will be more careful about this nomenclature in future. > 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. That's a good point. We could fall back onto a variety of devices if dummy is missing. Out of curiosity, what distros don't include dummy? > 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. Mixed feelings about the use of "tap". I changed a few locations, but I believe tap is widely referenced in the networking world as "test access point". At least Gigamon and Cisco use "tap" in reference to passive packet capture. This is a stylistic thing, but using tap in this context really feels natural to me. > > Best regards, Ilya Maximets. > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
