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 3DC1EA2F6B for ; Tue, 8 Oct 2019 06:16:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3145D1BFBF; Tue, 8 Oct 2019 06:16:05 +0200 (CEST) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by dpdk.org (Postfix) with ESMTP id AA70C1BFB7 for ; Tue, 8 Oct 2019 06:16:03 +0200 (CEST) Received: by mail-io1-f68.google.com with SMTP id c25so33577468iot.12 for ; Mon, 07 Oct 2019 21:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bLopVL61hQgJ9iEKVnYEpwpPjVVQMahlWsZU7eybYqM=; b=RCU92kHI/toAs2vQTL3Z/GQ/YZIyDETzji9d7lXMdeMrNIua3kEj4DG9xy+TUbTCJ1 kgbN3gpQoSwsjOMkEIp88r5Wj+X5TrY0pyHV/kzMpIHsXI6B8Vk2ZRm0g5mbVTvoxZQ0 AokuBZZCcoA6vki8BbE0HtRjjFXcQx2Pw+4CRJ/VumwLHAJIDxHa3TW7e/Vq/xAhZeRX tgvRRByXiYjEgiKyUO62dPExLfvvG33E8hr4YvlC2stA6YMMYeG9Ly024pp8VeviuAgV fXNu+w23JJ9iWPB6YpNuCurWbJTPjMK1ExjQ9jJf1FHJE5Y6oMl7zi2USqDeU03RXYkh Lcag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bLopVL61hQgJ9iEKVnYEpwpPjVVQMahlWsZU7eybYqM=; b=RiB9JYhXGcNRk7RE0PE1JtJwwCLODH5g1mole8JmwYsHj9h9MsMcq+9zikhpWjs/YX q+s7iHHp23ruJEdKm63jFsEuGXkXJflAPZ+t+QavgspyKXT9IBGtKIDfVjQDuQeu+UyI xd7OFoKFuXraxj22Q2BRKSJNVAXjnzqGURCg0kbSjWCxK0bNM1KcL/4vADtOmmDrYIwi LO2aCbVygG3uLomTkFfygUO/tcvqhR7/TelFfltfFLP0j7AIYs8ZMEPT87yotP/jeuRt oFKkkJuJKoqZ2ZoK/dYw7aIOkzskfoyGYeeBFCUj6QrfmImoTAbNaHUfFpAAasno9aIp r61Q== X-Gm-Message-State: APjAAAV0gq6sArU93AtVYept4q5OdmQLBFeTnTXNYoToZnwDr2bj589r NkxUUoIb8OwW/WcnBTptqpvxedvG6qWNdWj2vcDClkw4 X-Google-Smtp-Source: APXvYqxDKcNiQgkqlwOlOd0xRO/pooUTGmtH7/IFUm0+Y2TIBpuawIBIp9jw6lAOV1Q813c3a5N2VrjCszfxvZDktHY= X-Received: by 2002:a92:1598:: with SMTP id 24mr31963695ilv.60.1570508162715; Mon, 07 Oct 2019 21:16:02 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <20191007210113.0aa3a4d0@hermes.lan> From: Jerin Jacob Date: Tue, 8 Oct 2019 09:45:45 +0530 Message-ID: To: Stephen Hemminger Cc: dpdk-dev Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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, 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. >