Bug 1571884

ovs-tcpdump leverages OVS mirror to send to another port which is a kernel device. That's where regular tcpdump is attached. This method works regardless of the datapath is DPDK or KERNEL, which is great, but of course, the context switch imposes a performance penalty.

The other existing solution is dpdk-tcpdump but that requires the binaries to match in a level that becomes too fragile to run in any environment that matters.

I suspect you want a less intrusive traffic capture mechanism when using DPDK datapath.  One option would be use leverage OVS mirror again, but sending the copies to an OVS DPDKR port (rings), which is then pulled by an application at full core speed dumping to a buffer/file.

That would require to burn another CPU, at least, and memory to allocate the ring and yet there would be an impact when copying the packets. Maybe it is just better to capture in another point, for example, at the switch port?

fbl

Hi,

It's of course always an option to dump at the switch port but that doesn't capture packets somewhere on the virtualized path, e.g. for troubleshooting within the hypervisor. 

~~~
I suspect you want a less intrusive traffic capture mechanism when using DPDK datapath.  One option would be use leverage OVS mirror again, but sending the copies to an OVS DPDKR port (rings), which is then pulled by an application at full core speed dumping to a buffer/file.

That would require to burn another CPU, at least, and memory to allocate the ring and yet there would be an impact when copying the packets.
~~~
Is that a feature/path that's worth investigation? Let's keep this Bugzilla / RFE open and see if we get further feedback from the field.

- Andreas