From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by dpdk.org (Postfix) with ESMTP id 126BD374F for ; Mon, 14 Dec 2015 10:57:17 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Dec 2015 10:57:10 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC358AF758@smartserver.smartshare.dk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: tcpdump support in DPDK 2.3 Thread-Index: AdE2VczoK1KjRPfbTZOwcyLAzr7edQ== From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] tcpdump support in DPDK 2.3 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 09:57:17 -0000 I noticed a discussion about support for tcpdump in DPDK 2.3. =20 Please consider which scenarios you want to support: =20 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. =20 2. Compatibility with Wireshark? Check out the new "extcap" feature of Wireshark. It uses named pipes for = the packets, already mentioned by Stephen Hemminger. =20 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. =20 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! =20 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. =20 =20 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). =20 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. =20 =20 Med venlig hilsen / kind regards =20 Morten Br=F8rup CTO =20 =20 =20 SmartShare Systems A/S Tonsbakken 16-18 DK-2740 Skovlunde Denmark =20 Office +45 70 20 00 93 Direct +45 89 93 50 22 Mobile +45 25 40 82 12 =20 mb@smartsharesystems.com =20 www.smartsharesystems.com =20 =20