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 27A60A2F6B for ; Tue, 8 Oct 2019 06:01:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9140D1BFC3; Tue, 8 Oct 2019 06:01:53 +0200 (CEST) Received: from mail-pl1-f195.google.com (mail-pl1-f195.google.com [209.85.214.195]) by dpdk.org (Postfix) with ESMTP id B39C31BFB8 for ; Tue, 8 Oct 2019 06:01:51 +0200 (CEST) Received: by mail-pl1-f195.google.com with SMTP id j11so7900194plk.3 for ; Mon, 07 Oct 2019 21:01:51 -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=CuUQxy+0P0qWSSRRNBdNeXGxHQj1KtWwSNMoEJmwKQA=; b=BbvDdrtqzm12jbrgRF5yzLNvQcdAXcF3ffr2o/2mcXeyG2GFA93Ra6MdxEwm6lgYrw rG5ICR9JjdJuw8cCUYswOJBmQcfUJw7Phrftp/KS1vjzUSY3Pr7jg6CS5TMJ/siYGRha vojwMuq/RvwHefTiu3+jfg+pSbg9/uP+FlihBbaU+fQzrDnqtIT5vniF/7vbOER/6xQq MBVCcUHGP29lp6S23GpNvBcdo0AjFYT9ZSWArod0ZftcxuFAhHmwpJxTIlDTu0YX1nLU VJTwxkRwmtZON7s1wfg2AeEsID15fVTvrvewBaph8SHW2kyUz7GueiA1SdY8NuA6sfJF BEOQ== 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=CuUQxy+0P0qWSSRRNBdNeXGxHQj1KtWwSNMoEJmwKQA=; b=HtCnnvdKR1mgQTW7CcEas36I/FiUoh5Axi7aI8KqDRL38D2JlPYq2/q9JdE3XUJZpW NYVUToKnEROZZ9fbP2EGf2wxl32HcAaDU/mXsl9bIPumBhRDE297m+Bc/iAzcs7W346G CpHqzCGiAC6XZehe4PyxHGkr9lUPX+KUoK3gJ7llEKZ08ahQewN5J+xpJD2Wat9f0EPR Et/njeyd4Uxk8bIanvHNJ9CWm+VNmGPOTRplZNN3iylb2ncYvADkAZr/8/orUnyqt+/p iiKgjDURwFVbP0/uS0K+ulk5gpQVp/I0vRp2zEhvJg9cKdQQmSQYK7nyxqH6IgIE2Q9V 4WyA== X-Gm-Message-State: APjAAAUOET+sKcWXMOx2BDDQrURnj5Alb6brzExWslen1Y3HgK6hucny RbTCBwilXb9dun4MMVcZgMlp8w== X-Google-Smtp-Source: APXvYqxiid7MVBlbwOxpjP++pV/i8qGHzqCQJ1b28re/g9WdC2W52X6aqajeJSbl2JtEMuvBKde+fA== X-Received: by 2002:a17:902:6e17:: with SMTP id u23mr32949541plk.205.1570507310472; Mon, 07 Oct 2019 21:01:50 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id q13sm744054pjq.0.2019.10.07.21.01.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Oct 2019 21:01:50 -0700 (PDT) Date: Mon, 7 Oct 2019 21:01:13 -0700 From: Stephen Hemminger To: Jerin Jacob Cc: dpdk-dev Message-ID: <20191007210113.0aa3a4d0@hermes.lan> In-Reply-To: References: <20191007165232.14535-1-stephen@networkplumber.org> <20191007165232.14535-6-stephen@networkplumber.org> <20191007103343.6d199594@hermes.lan> <20191007144543.46666c2d@hermes.lan> 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 Tue, 8 Oct 2019 09:17:08 +0530 Jerin Jacob wrote: > On Tue, 8 Oct, 2019, 3:15 AM Stephen Hemminger, > wrote: > > > On Tue, 8 Oct 2019 01:03:17 +0530 > > Jerin Jacob wrote: > > > > > On Mon, 7 Oct, 2019, 11:03 PM Stephen Hemminger, < > > stephen@networkplumber.org> > > > wrote: > > > > > > > On Mon, 7 Oct 2019 22:37:43 +0530 > > > > Jerin Jacob wrote: > > > > > > > > > On Mon, 7 Oct, 2019, 10:23 PM Stephen Hemminger, < > > > > stephen@networkplumber.org> > > > > > wrote: > > > > > > > > > > > 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.