On Tue, 8 Oct, 2019, 3:15 AM Stephen Hemminger, <[email protected]> wrote:
> On Tue, 8 Oct 2019 01:03:17 +0530 > Jerin Jacob <[email protected]> wrote: > > > On Mon, 7 Oct, 2019, 11:03 PM Stephen Hemminger, < > [email protected]> > > wrote: > > > > > On Mon, 7 Oct 2019 22:37:43 +0530 > > > Jerin Jacob <[email protected]> wrote: > > > > > > > On Mon, 7 Oct, 2019, 10:23 PM Stephen Hemminger, < > > > [email protected]> > > > > 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.
