From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by dpdk.org (Postfix) with ESMTP id 33CB4B62 for ; Mon, 14 Dec 2015 20:14:35 +0100 (CET) Received: by pacwq6 with SMTP id wq6so108140240pac.1 for ; Mon, 14 Dec 2015 11:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=80xfqHlmOGyKUrguCxqgkZPBOOX5X81MaF0pLLG0GMg=; b=rrijcBBxyVOVtP+cydtk/XBsVRCDTDsLv4K1NEIxTgQhhl3EGNE0VT7m5YwtKzaRl8 wUvVOmoyg/FUGdY6y3Sevsc1D32aIims1ftnsoHfQSwemONZj3M5MTI8yhwojt17oica MbeDHvypTL7RNY/Zy/aDX4LPwVikod9lXkKY+c0zMuLRaE2ZR+ed2hiqJAcEC5D2wCjN 0PDMn9+FV+DcMfNv8lFVhKoAkxDK9kFGz1XL9kgGGc7Rh+H6hIBKEFmgz9KiJu/AVLY1 BORhqKUZQFadIdw1AS7/c02eba/KAM/xlkSG0mL/+/zc1EP3b7RXLsMxbNxm93T/D1ZP uctg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=80xfqHlmOGyKUrguCxqgkZPBOOX5X81MaF0pLLG0GMg=; b=NcR3vJuOB5nbONbK/eryzPgms4XfM7ru1JZ8ETkMma+3/7VHWfOwtk9HpqkeIiN1MK wLgL+yKGbvThray+NHs+8f/I/yLyYM2h0qIEC2uwvbuRsmXzMHg6QQMW+kAF3ndX0OgY ELQoZsislzsqJyoetI62nzpP/FuWKIm7nGm3Y2CmXW8qM3HdmYDcpk7ElknTflb5gyI8 I6br4yZR+jYtF5w8awoSntp1QxyAYdO4JFEth/CvV83S6tKRcRf+VnmrzcHQFdIMLW/4 BzX5qypjGuybC2qhcUY+p6dnO0Ck7ZYSYT6iInu64UnuwDZsU8Yx84pVCbXBBs01EvKo Xuzg== X-Gm-Message-State: ALoCoQmMbqAwgUq5W4mZaz9K22MwkhDjIujeg9/75LCoM97tAE70k3lTjXe8wZnD6Ru8mLQlm+kytLywEXB0noKNTMGf/gO2aw== X-Received: by 10.66.180.99 with SMTP id dn3mr23582156pac.85.1450120474494; Mon, 14 Dec 2015 11:14:34 -0800 (PST) Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id w85sm44025893pfa.48.2015.12.14.11.14.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Dec 2015 11:14:34 -0800 (PST) Date: Mon, 14 Dec 2015 11:14:42 -0800 From: Stephen Hemminger To: Matthew Hall Message-ID: <20151214111442.6328dde9@xeon-e3> In-Reply-To: <20151214182931.GA17279@mhcomputing.net> References: <98CBD80474FA8B44BF855DF32C47DC358AF758@smartserver.smartshare.dk> <20151214182931.GA17279@mhcomputing.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, Morten B Subject: Re: [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 19:14:35 -0000 On Mon, 14 Dec 2015 13:29:31 -0500 Matthew Hall 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.