> I agree fixing offsets in cbpf to ebpf converter and passing mbuf is easier.
> There is still the pathological case of multi segment mbuf. But
> Linux XDP doesn't handle it either.
Why do you think multi-seg would be a problem?
If we’ll use rte_pktmbuf_read() for interpreter and something simil
I agree fixing offsets in cbpf to ebpf converter and passing mbuf is
easier. There is still the pathological case of multi segment mbuf. But
Linux XDP doesn't handle it either.
Let me put early version of filter2rteebf on GitHub
On Thu, Feb 6, 2020, 8:54 AM Morten Brørup wrote:
> > From: dev [m
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev,
> Konstantin
> Sent: Wednesday, February 5, 2020 10:16 PM
>
> >
> > As I mentioned in my FOSDEM talk the current DPDK eBPF handling is
> > not usable for packet filters. I have ported the classic BPF to eBPF
> code
> > and the generat
On Thu, Feb 6, 2020 at 2:46 AM Ananyev, Konstantin
wrote:
>
> >
>
> Second question is implementation.
> I can see two main options here:
> a) if we plan to have our own cBPF->eBPF converter and support only it,
> we can add these extra instructions generation into converter itself.
> I.E. cBPF->
>
> As I mentioned in my FOSDEM talk the current DPDK eBPF handling is
> not usable for packet filters. I have ported the classic BPF to eBPF code
> and the generated code is not usable by DPDK.
>
> The problem is that DPDK eBPF does not implement all the opcodes.
> BPF_ABS is not implemented and
As I mentioned in my FOSDEM talk the current DPDK eBPF handling is
not usable for packet filters. I have ported the classic BPF to eBPF code
and the generated code is not usable by DPDK.
The problem is that DPDK eBPF does not implement all the opcodes.
BPF_ABS is not implemented and must be. It is
6 matches
Mail list logo
