From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 82295A3160 for ; Wed, 9 Oct 2019 16:59:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 366D51E8A7; Wed, 9 Oct 2019 16:59:48 +0200 (CEST) Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) by dpdk.org (Postfix) with ESMTP id 7888C1E886 for ; Wed, 9 Oct 2019 16:59:47 +0200 (CEST) Received: by mail-pl1-f196.google.com with SMTP id j11so1184089plk.3 for ; Wed, 09 Oct 2019 07:59:47 -0700 (PDT) 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-transfer-encoding; bh=uRFbmwrnq5rBNOyV+y2VuaqXY3u3eRAuN+lO3cUwF/g=; b=Zc5b9/17P5f0JwQED3Nj704Z/rc2rD4pSBTWBfbT8Loe4hLAqQLQPK11507OBzZ6rU JsJycr4aeBiqZ+Hs7CrdajbIhaGcY43wrZTmAOtGAL5GrhmXA4QcMpX/lAbEiMXq8JWG Z4MDXf1Qh6VIx9jrvIs5q6Kq7+XsGYaFuHV35LrjPP0BJx8tjA0wjewdQHWL/IMGz16r jf7PKs388adhPDmAf6VPRHaqHVg7eAG9KttZsodVXMdw384FysclnBc/cb9CedcFblvE E0CpGm3SNWA6tprQO2d0NlgHF8PKdgk8x/RWHFTGbW35dqAMN1WL3ySn3yR7nqBSBP6T tExw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=uRFbmwrnq5rBNOyV+y2VuaqXY3u3eRAuN+lO3cUwF/g=; b=p6SnhDU0D6E5ICiD5spNYIkQecpNcV4AA+2SQTyclzIX6MD2EqlZc2OL+rGrLEn9qH RoBv/1vciNOCmvjGL7yMxpkRfUC13NfQ9KpeRQwQPPQd88B44V+Euynbyp3dDp6LZIBw 7tp5cRIB7vnYzt6O27YHOT2hkxcMSO2l3IxE1Q/auXnPijnRn9DA8HKGlHI0UiZ0j6Hm V2bxM9k9yhh1FZQzZ7i1A90isxdB+CATWFl4j5ea6GWX0Xgut5HQQnAlebTYqP/HqE/P At8De6E409oTG1OmqbRLPKsl9YY4kL/M/x3eNnMu7suKeutqoP1d4+dwKiSkBjmYHXlt Hqqw== X-Gm-Message-State: APjAAAXTfXYoMb9U8Q+ohSoeXjq2/5XZ7VrYc2ilOfPUAvO1O/PEtL6y DJbvBLZmnIwBAFOZcOIrrX7G0w== X-Google-Smtp-Source: APXvYqwneN6TOmEePhdyeG3NnuNs5dlN4s8+TrZXhpOudqGyPbIVnz98iL+5PGbxEkgG1rgT7HgrXQ== X-Received: by 2002:a17:902:778a:: with SMTP id o10mr3542814pll.93.1570633186350; Wed, 09 Oct 2019 07:59:46 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id z4sm2728326pjt.17.2019.10.09.07.59.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Oct 2019 07:59:46 -0700 (PDT) Date: Wed, 9 Oct 2019 07:59:38 -0700 From: Stephen Hemminger To: "Ananyev, Konstantin" Cc: 'Morten =?UTF-8?B?QnLDuHJ1cCc=?= , Jerin Jacob , dpdk-dev Message-ID: <20191009075938.5132ff0e@hermes.lan> In-Reply-To: <2601191342CEEE43887BDE71AB9772580191974054@irsmsx105.ger.corp.intel.com> References: <20191007165232.14535-1-stephen@networkplumber.org> <20191007165232.14535-6-stephen@networkplumber.org> <20191007103343.6d199594@hermes.lan> <20191007144543.46666c2d@hermes.lan> <20191007210113.0aa3a4d0@hermes.lan> <20191007212256.4bf37797@hermes.lan> <98CBD80474FA8B44BF855DF32C47DC35C60B63@smartserver.smartshare.dk> <2601191342CEEE43887BDE71AB9772580191974054@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC 5/8] pdump: add classic BPF filtering X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, 9 Oct 2019 08:21:42 +0000 "Ananyev, Konstantin" wrote: > Hi everyone, > > > > > > > > > > > > Simple classic BPF interpreter based off of libpcap. > > > > > > > > > > > > > > > > > > > > > > This is a copy of the BPF interpreter from libpcap which is > > > > > > > > > > > modified to handle mbuf meta data. The existing > > > > > pcap_offline_filter > > > > > > > > > > > does not expose a way to match VLAN tags. Copying the BPF > > > > > > > interpreter > > > > > > > > > > > also means that rte_pdump still does not have a hard > > > dependency > > > > > > > > > > > on libpcap. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why not use DPDK's librte_bpf library? Rather implementing > > > cBPF > > > > > > > > > > interpreter. Currently it supports eBPF which is super set of > > > > > > > cBPF.if is > > > > > > > > > > this features very specific to cBPF, we clould simply > > > implement > > > > > > > cBPF > > > > > > > > > using > > > > > > > > > > eBPF or implement a new cBPF program type. That scheme could > > > > > leverage > > > > > > > > > > existing JIT infrastructure also. Using JIT will improve > > > > > filtering > > > > > > > > > > performance. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Because pcap library generates cBPF in its string to BPF > > > compiler. > > > > > > > > > Translating cBPF to eBPF is non trivial. > > > > > > > > > > > > > > > > > > > > > > > > > Then at least cBPF interpreter should move to librte_bpf. We can > > > > > hook to > > > > > > > > JIT if required in future. > > > > > > > > > > > > > > The opcodes for cBPF and eBPF are not compatiable. > > > > > > > > > > > > > > > > > > > Yeah. I am saying to add new program type in bpf library of cBPF. > > > > > Obviously > > > > > > pdump is not the correct place for cBPF interpreter. Moving to > > > rte_libbpf > > > > > > library would help to enable other applications or libraries to use > > > cBPF > > > > > > bpf program class. > > > > > > > > > > The problem is you need a version of string to BPF program which is > > > what > > > > > the libpcap pcap_compile() function does for you. eBPF as used now is > > > all > > > > > about having a full language (CLANG or GCC) and that is not what is > > > needed > > > > > here at all. The problem is not the interpreter, the problem is on the > > > > > userspace BPF side. Until/unless that is fixed, cBPF is a better > > > solution. > > > > > > > > > > > > > > > > > I am not saying to use eBPF with libpcap. All I am saying to move the > > > cBPF > > > > interpreter code(this patch) to rte_libbpf as it is the correct place of > > > > that code in DPDK PoV. So that it can be used by another applications or > > > > library. > > > > > > > > > > > > > > > Sure that make sense? > > For me yes, what Jerin suggests does make sense. > We probably can extend rte_bpf_load to accept both ebpf and cbpf bytecode. > Or create a new function: cbpf_load() and make bpf_exec() to be able to execute both ISA. > Then pdump library can support both flavors (eBPF and cBPF). > Stephen, not sure I understand - what is your concern with such approach? > > > > > Initially, I would have said yes, because we already implemented our own cBPF interpreter that way. However, we are using it for packet > > capture only, and I cannot see any other use for it - except perhaps filtered port mirroring, but that is just another form of packet capturing. > > So it might as well stay with the packet capture library. > > > > > > And here goes my rant against eBPF: > > > > In my opinion, eBPF and cBPF are two completely different things... If only rte_libbpf was named rte_libebpf. Then we could have the cBPF > > interpreter as rte_libbpf or rte_libcbpf. > > I think we still can have it, see above. > > > > > I would like to elaborate Stephen's comment about the main thing being the integration with userspace: > > cBPF has a range of easily accessible tools readily available for use by network operators, such as tcpdump. I consider eBPF for > > programmers only. > > A real life example: Our network appliance provides a GUI. The packet capture feature has a filter field where you can provide a cBPF > > program in the form of a hex string, which a network operator basically can create by using tcpdump with the right parameters on his > > laptop. I cannot imagine any network operator sitting down to write an eBPF program for capturing e.g. packets with UDP source port 53 > > and IP source address 1.1.1.1. > > As I can read your main complaint is not about eBPF itself, but about luck of eBPF code generation tools... > AFAIK for kernel guys it is not a problem, as in kernel cBPF bytecode always converted to eBPF one before execute/JIT. > Probably we just need the same ability in user-space. Since the DPDK API needs to copy (to rte_malloc memory) and validate the capture filter, Lets investigate something net/core/filter.c:bpf_convert_filter in Linux.