[dpdk-dev] tcpdump support in DPDK 2.3

[Stephen Hemminger]

On Mon, 14 Dec 2015 13:29:31 -0500
Matthew Hall <mhall at mhcomputing.net> wrote:

> FYI your last name comes in as a corrupt character for me. You might have to 
> think about converting it from ISO 8859-1 / 8859-15 to UTF-8.
> 
> On Mon, Dec 14, 2015 at 10:57:10AM +0100, Morten B wrote:
> > Check out the new "extcap" feature of Wireshark. It uses named pipes for the 
> > packets, already mentioned by Stephen Hemminger.
> 
> I looked at it a bit. I wasn't 100% clear if there is a way to pass down the 
> BPF expression for compilation and usage inside the DPDK application.
> 
> > Tcpdump is an open source application, so it should be possible to define an 
> > efficient interface between DPDK and tcpdump, and implement it in both DPDK 
> > and tcpdump. The same goes for libpcap.
> 
> Easier said than done. A whole ton of libpcap assumes it's talking to a very 
> specific kernel interface, and the code is quite complicated.
> 
> > It possibly also has a secondary feature: passing a BPF program 
> > from tcpdump/libpcap to DPDK, so packets can be filtered in DPDK and don't 
> > need to be passed on to tcpdump/libpcap.
> 
> If we can figure out how to get this feature to work in extcap, I think that 
> will be the winning solution by far.
> 
> > [A]dd a BPF library (librte_bpf) to DPDK, preferably with a compiler. The 
> > application initially calls the library's BPF compiler function once with 
> > the BPF program to compile it, and in the fast path the application calls a 
> > library function that takes an mbuf and the compiled BPF program and returns 
> > an integer value indicating how many bytes of the packet should be mirrored 
> > by the capturing application. +1 to Matthew Hall for taking this direction!

There are already several BPF libraries available. I would prefer DPDK not
start copying existing code.