Re: [dpdk-dev] [RFC 5/8] pdump: add classic BPF filtering

["Morten Brørup" <mb@smartsharesystems.com>]

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