dev.dpdk.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "'Morten Brørup'" <mb@smartsharesystems.com>,
	"Jerin Jacob" <jerinjacobk@gmail.com>, dpdk-dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC 5/8] pdump: add classic BPF filtering
Date: Wed, 9 Oct 2019 07:59:38 -0700	[thread overview]
Message-ID: <20191009075938.5132ff0e@hermes.lan> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772580191974054@irsmsx105.ger.corp.intel.com>

On Wed, 9 Oct 2019 08:21:42 +0000
"Ananyev, Konstantin" <konstantin.ananyev@intel.com> 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.


  reply	other threads:[~2019-10-09 14:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-07 16:52 [dpdk-dev] [RFC 0/8] Packet Capture enhancements Stephen Hemminger
2019-10-07 16:52 ` [dpdk-dev] [RFC 1/8] pdump: use new pktmbuf copy function Stephen Hemminger
2019-10-07 16:52 ` [dpdk-dev] [RFC 2/8] pdump: use dynamic logtype Stephen Hemminger
2019-10-07 16:52 ` [dpdk-dev] [RFC 3/8] pdump: tag copied mbuf with port Stephen Hemminger
2019-10-07 16:52 ` [dpdk-dev] [RFC 4/8] pdump: stamp packets with current timestamp Stephen Hemminger
2019-10-07 16:52 ` [dpdk-dev] [RFC 5/8] pdump: add classic BPF filtering Stephen Hemminger
2019-10-07 17:07   ` Jerin Jacob
2019-10-07 17:33     ` Stephen Hemminger
2019-10-07 19:33       ` Jerin Jacob
2019-10-07 21:45         ` Stephen Hemminger
2019-10-08  3:47           ` Jerin Jacob
2019-10-08  4:01             ` Stephen Hemminger
2019-10-08  4:15               ` Jerin Jacob
2019-10-08  4:22                 ` Stephen Hemminger
2019-10-08 21:08                   ` Morten Brørup
2019-10-09  8:21                     ` Ananyev, Konstantin
2019-10-09 14:59                       ` Stephen Hemminger [this message]
2019-10-07 16:52 ` [dpdk-dev] [RFC 6/8] pdump: add packet header truncation Stephen Hemminger
2019-10-07 16:52 ` [dpdk-dev] [RFC 7/8] pcapng: add new library for writing pcapng files Stephen Hemminger
2019-10-07 16:52 ` [dpdk-dev] [RFC 8/8] app/capture: add packet capture using pcapng Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191009075938.5132ff0e@hermes.lan \
    --to=stephen@networkplumber.org \
    --cc=dev@dpdk.org \
    --cc=jerinjacobk@gmail.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=mb@smartsharesystems.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).