Re: [dpdk-dev] 2.3 Roadmap

[Matthew Hall <mhall@mhcomputing.net>]

On Wed, Dec 02, 2015 at 01:38:07AM +0000, Wiles, Keith wrote:
> In Pktgen I used tap interface to wireshark and that worked very nicely the 
> only problem is it was slow :-(
> 
> Having a tap PMD would be nice to be able to remove that code from Pktgen.

All these approaches we discussed so far have a serious architectural issue. 
The entire point of BPF / libpcap was to prevent crossing unnecessary system 
boundaries with an arbitrarily, unsustainably large volume of unfiltered 
packets which will be tossed out anyways thereafter as they are irrelevant to 
a particular debugging objective.

In the past it was the kernel -> user boundary.

In our case it is the Data Plane -> Management Plane boundary.

If we don't use something similar to libpcap offline mode (which I am using 
presently in my code) or preferably the user-space bpfjit (which I am working 
up to using eventually), it's going to be more or less impossible for this to 
work properly and not blow stuff up with anything close to wirespeed traffic 
going through the links being monitored. Especially with 10, 40, 100, ad 
nauseam, gigabit links.

With the classic BPF / libpcap, it's absolutely possible to get it to work, 
without causing a big performance problem, or causing a huge packet dump 
meltdown, or any other issues in the process. We need to find a way to achieve 
the same objective in our new environment as well.

One possible option, if some kernel guys could assist with figuring out the 
trick, would be if we could capture the BPF ioctl / syscall / whatever it 
secretly does on the TAP or KNI interface, when it passes the capture filter 
to the kernel, and steal the filter for use in pcap offline or userspace 
bpfjit inside of DPDK. Then supply only the packets meeting the filter back 
onto said interface.

Matthew.