From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFB69C4360C for ; Tue, 8 Oct 2019 04:23:08 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id BB500206BB for ; Tue, 8 Oct 2019 04:23:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20150623.gappssmtp.com header.i=@networkplumber-org.20150623.gappssmtp.com header.b="eiG0eXDt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BB500206BB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=networkplumber.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 56C5F1BFD9; Tue, 8 Oct 2019 06:23:06 +0200 (CEST) Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by dpdk.org (Postfix) with ESMTP id 2790E1BFD7 for ; Tue, 8 Oct 2019 06:23:04 +0200 (CEST) Received: by mail-pg1-f196.google.com with SMTP id i32so2238592pgl.10 for ; Mon, 07 Oct 2019 21:23:03 -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=9sJ2ruFaL039JomJPFpfHp2v8hCaMuZ8Je8N93S79Ik=; b=eiG0eXDt7n5uZxQ+2te6n7rLtDnbyevveA9AFydMHaqXAbBlQdAd16mFb34UmZJiKp uby4/vra5sQkvdr3K68DLeVbkZonu+v9DPO63igujAKo7QPV/nUS2QY8L2KhRVnA4Oak ZBw1bixBX+JGSF4sdLe3ScjUC3Z9WA1kI3LBdycWuIToWSQgeTOszJRw+6AUCfM2S4tO 5xduHvg2mEk1SKoxjmYQMyzU5ZPrQ4rU5LBL+A5K3vAZAQMxNlLFJ1PmAKIBLaMlhyVw TTjFy7GCmhvASctx5MmkRNe6il8eBescANybN6ufXW0jK+R6quWr2JimIn54vA/qdRDw 1qCg== 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=9sJ2ruFaL039JomJPFpfHp2v8hCaMuZ8Je8N93S79Ik=; b=Yo+rHagHfVORapG7gGyFoIy7X0ROyLNfxCnsFIr4xRdK1aBaL7Gakd4tDTeyVEgeu7 OlUUh8zNctXhYEBPml+KKsYF2VKNceJdZqYhoalzLnZdLtjjLCjOY+OEXDNqTZCT7AjI vWdBWnKvmbCSzDCQRILU4l2QjirTVs+lhZISJpDgknOLx2mEnYsoVVjwQjmwQgfa1xVC zz2Pjb8nF65LBxJMqH/QuhRF9HpxR7MDGzZJi0yX2SRSYDiqTnjqIfOjFUKierr9w/+B GtjwraBoQ/u6wImWWn95LojEbNjGnRBmDqqf9QrjaIhU5f03ptC6Fh2wBq2yOb6O2q0E 1O7Q== X-Gm-Message-State: APjAAAXKL92//VzLfJVCJe5hqTfAtJI9BJu/qC0kNmCJQeIkMaHmqHRY 3DVNMfRpGDDJEN7Y2hnlVJS0yQ== X-Google-Smtp-Source: APXvYqzH5BzcwCrRj/7WrQSwce1+ltkWK2U6OIPYm2cmJD6DAMJ1hXxbhVcPeFdSwD/QlD4oM6pk1Q== X-Received: by 2002:a17:90a:80c9:: with SMTP id k9mr3394968pjw.70.1570508582818; Mon, 07 Oct 2019 21:23:02 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id k15sm16002817pfa.65.2019.10.07.21.23.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Oct 2019 21:23:02 -0700 (PDT) Date: Mon, 7 Oct 2019 21:22:56 -0700 From: Stephen Hemminger To: Jerin Jacob Cc: dpdk-dev Message-ID: <20191007212256.4bf37797@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> <20191007210113.0aa3a4d0@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:45:45 +0530 Jerin Jacob wrote: > On Tue, 8 Oct, 2019, 9:31 AM Stephen Hemminger, > wrote: > > > On Tue, 8 Oct 2019 09:17:08 +0530 > > Jerin Jacob wrote: > > > > > On Tue, 8 Oct, 2019, 3:15 AM Stephen Hemminger, < > > stephen@networkplumber.org> > > > 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. > > > > > 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?