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

[Stephen Hemminger <stephen@networkplumber.org>]

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.