Re: [dpdk-dev] [PATCH 0/8] eBPF arm64 JIT support

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

Hi guys,
 
> On Fri, Oct 4, 2019 at 7:39 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> >
> > On 10/4/19 12:53 PM, Thomas Monjalon wrote:
> > > 04/10/2019 11:54, Steve Capper:
> > >> I'd recommend also reaching out the BPF maintainers:
> > >> BPF JIT for ARM64
> > >> M:   Daniel Borkmann <daniel@iogearbox.net>
> > >> M:   Alexei Starovoitov <ast@kernel.org>
> > >> M:   Zi Shen Lim <zlim.lnx@gmail.com>
> > >> L:   netdev@vger.kernel.org
> > >> L:   bpf@vger.kernel.org
> > >> S:   Supported
> > >> F:   arch/arm64/net/
> > >>
> > >> As they will have much better knowledge of the state of play and will be
> > >> better able to advise.
> > >
> > > As far as I know Alexei and Daniel are OK with the idea.
> > > But better to let them reply here.
> > >
> > > I suggest we think about a way to package the kernel BPF JIT
> > > for userspace usage (not only DPDK) as a library.
> > > I don't understand why the DPDK JIT should be different
> > > or optimized differently.
> >
> > That would be great indeed as both projects would benefit from a shared
> > JIT instead of reimplementing everything twice. I never looked into DPDK
> > too much, but I presume the idea would be as well to take the LLVM (or
> > bpf-gcc) generated object file and load it into a BPF 'engine' that sits
> > in user space on top of DPDK? Presumably loader could be libbpf here as
> > well since it already knows how to parse the ELF, perform the relocations
> > etc. The only difference would be that you have a different context and
> > different helpers? Is that the goal eventually?
> >
> > > The only real issue I see is the need for a dual licensing BSD-GPL.
> >
> > This might be one avenue if all kernel JIT contributors would be on board.
> > Another option I'm wondering could be to extend the bpf() syscall in order
> > to pass down a description of context and helper mappings e.g. via BTF and
> > let everything go through the verifier in the kernel the usual way (I presume
> > one goal might be that you want to assure that the generated BPF code passes
> > the safety checks before running the prog), then have it JITed and extract
> > the generated image in order to use it from user space. Kernel would have
> > to make sure it never actually allows attaching this program in the kernel.
> > Generated opcodes can already be retrieved today (see below). Such infra
> > could potentially help bpf-gcc folks as well as they expressed desire to
> > have some sort of a simulator for their gcc BPF test suite.. and it would
> > allow for consistent behavior of the BPF runtime. Just a thought.
> 
> This idea looks good. This can remove the verifier code also from DPDK.
>  A couple of downsides I can think of,
> 
> # We may need to extend the kernel verifier to understand the user-space address
> and its symbols for CALL and MEM access operations.
> # DPDK supports FreeBSD and Windows OS as well
> # Need a different treatment for old Linux kernels.

Seems like discussion died out eventually.
Pinging to check is there still any interest on that subject
from kernel community.
Thanks
Konstantin