DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Stephen Hemminger" <stephen@networkplumber.org>,
	"Jerin Jacob" <jerinjacobk@gmail.com>
Cc: "dpdk-dev" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC 5/8] pdump: add classic BPF filtering
Date: Tue, 8 Oct 2019 23:08:37 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C60B63@smartserver.smartshare.dk> (raw)
In-Reply-To: <20191007212256.4bf37797@hermes.lan>

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Tuesday, October 8, 2019 6:23 AM
> 
> On Tue, 8 Oct 2019 09:45:45 +0530
> Jerin Jacob <jerinjacobk@gmail.com> wrote:
> 
> > On Tue, 8 Oct, 2019, 9:31 AM Stephen Hemminger,
> <stephen@networkplumber.org>
> > wrote:
> >
> > > On Tue, 8 Oct 2019 09:17:08 +0530
> > > Jerin Jacob <jerinjacobk@gmail.com> 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 <jerinjacobk@gmail.com> 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 <jerinjacobk@gmail.com> 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?

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 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.


Med venlig hilsen / kind regards
- Morten Brørup


  reply	other threads:[~2019-10-08 21:08 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 [this message]
2019-10-09  8:21                     ` Ananyev, Konstantin
2019-10-09 14:59                       ` Stephen Hemminger
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=98CBD80474FA8B44BF855DF32C47DC35C60B63@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=dev@dpdk.org \
    --cc=jerinjacobk@gmail.com \
    --cc=stephen@networkplumber.org \
    /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).