Hi guys, > On Fri, Oct 4, 2019 at 7:39 PM Daniel Borkmann <dan...@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 <dan...@iogearbox.net> > > >> M: Alexei Starovoitov <a...@kernel.org> > > >> M: Zi Shen Lim <zlim....@gmail.com> > > >> L: net...@vger.kernel.org > > >> L: b...@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
