I noticed a discussion about support for tcpdump in DPDK 2.3.
Please consider which scenarios you want to support: 1. Compatibility with legacy non-DPDK applications (e.g. a DHCP server application) that captures specific packets by opening RAW sockets and attaching BPF filters to these sockets? I agree that KNI (or TUN/TAP for the non-KNI kernels) is a realistic and simple way to interact with the kernel regarding raw packet capture, which might be filtered by the kernel. In this case, all packets will be passed on from DPDK to the kernel, which will handle the BPF filtering, and then pass up the packets to the application. 2. Compatibility with Wireshark? Check out the new "extcap" feature of Wireshark. It uses named pipes for the packets, already mentioned by Stephen Hemminger. 3. tcpdump/libpcap support? 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. An efficient interface has a primary feature: passing packets from DPDK to tcpdump/libpcap without too much overhead. 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. 4. Efficient fast path packet filtering using BPF? Technically, this has nothing to do with tcpdump. Just add 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! 5. Pcap formatted output? The pcap file format contains a header in front of each packet, which is extremely simple. But it has a timestamp (which uses 32 bit for tv_sec and tv_usec in files), so it needs to be considered how to handle this efficiently. PS: Remember that the packets received on the port might be distributed to multiple lcores by RSS, and all these lcores need to write to a single queue (named pipe, TUN/TAP port, pcap file, or whatever). PPS: Bruce Richardson suggested adding a port mirroring callback. If you want port mirroring or tcpdump support in your application, it belongs in your application. Callbacks come at a cost (especially if not used), so don't start adding callbacks and hooks for new features if not strictly required. You might also want port mirroring or tcpdump support for something further down the application's fast path, e.g. mirroring PPPoE tunneled packets after they come out of the PPPoE tunnel. In this case, you need to add it to your application anyway. Med venlig hilsen / kind regards Morten Br?rup CTO SmartShare Systems A/S Tonsbakken 16-18 DK-2740 Skovlunde Denmark Office +45 70 20 00 93 Direct +45 89 93 50 22 Mobile +45 25 40 82 12 mb at smartsharesystems.com <mailto:mb at smartsharesystems.com> www.smartsharesystems.com <http://www.smartsharesystems.com/>
