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

[Stephen Hemminger]

On Tue, 8 Oct 2019 09:45:45 +0530
Jerin Jacob <jerinjacobk at gmail.com> wrote:

> On Tue, 8 Oct, 2019, 9:31 AM Stephen Hemminger, <stephen at networkplumber.org>
> wrote:
> 
> > On Tue, 8 Oct 2019 09:17:08 +0530
> > Jerin Jacob <jerinjacobk at gmail.com> wrote:
> >  
> > > On Tue, 8 Oct, 2019, 3:15 AM Stephen Hemminger, <
> > stephen at networkplumber.org>
> > > wrote:
> > >  
> > > > On Tue, 8 Oct 2019 01:03:17 +0530
> > > > Jerin Jacob <jerinjacobk at gmail.com> wrote:
> > > >  
> > > > > On Mon, 7 Oct, 2019, 11:03 PM Stephen Hemminger, <
> > > > stephen at networkplumber.org>
> > > > > wrote:
> > > > >  
> > > > > > On Mon, 7 Oct 2019 22:37:43 +0530
> > > > > > Jerin Jacob <jerinjacobk at gmail.com> wrote:
> > > > > >  
> > > > > > > On Mon, 7 Oct, 2019, 10:23 PM Stephen Hemminger, <
> > > > > > stephen at 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?