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.