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

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

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.

> 
> Med venlig hilsen / kind regards
> - Morten Brørup