DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerinjacobk@gmail.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	Steve Capper <Steve.Capper@arm.com>,
	"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	 Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	Rodolph Perfetta <Rodolph.Perfetta@arm.com>,
	 "jerinj@marvell.com" <jerinj@marvell.com>,
	dpdk-dev <dev@dpdk.org>,
	 "Gavin Hu (Arm Technology China)" <Gavin.Hu@arm.com>,
	nd <nd@arm.com>, Alexei Starovoitov <ast@kernel.org>,
	 Quentin Monnet <quentin.monnet@netronome.com>,
	john.fastabend@gmail.com
Subject: Re: [dpdk-dev] [PATCH 0/8] eBPF arm64 JIT support
Date: Fri, 4 Oct 2019 20:13:01 +0530	[thread overview]
Message-ID: <CALBAE1PYX4VsuMc5s17opLxgM2uD0JE5NGX-awLqqXJPJ7gffw@mail.gmail.com> (raw)
In-Reply-To: <5231837e-3813-0eeb-1c87-5b7072cf8c18@iogearbox.net>

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.




>
>

  reply	other threads:[~2019-10-04 14:43 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-03 10:59 jerinj
2019-09-03 10:59 ` [dpdk-dev] [PATCH 1/8] bpf/arm64: add build infrastructure jerinj
2019-09-03 10:59 ` [dpdk-dev] [PATCH 2/8] bpf/arm64: add prologue and epilogue jerinj
2019-09-03 10:59 ` [dpdk-dev] [PATCH 3/8] bpf/arm64: add basic arithmetic operations jerinj
2019-09-03 10:59 ` [dpdk-dev] [PATCH 4/8] bpf/arm64: add logical operations jerinj
2019-09-03 10:59 ` [dpdk-dev] [PATCH 5/8] bpf/arm64: add byte swap operations jerinj
2019-09-03 10:59 ` [dpdk-dev] [PATCH 6/8] bpf/arm64: add load and store operations jerinj
2019-09-03 10:59 ` [dpdk-dev] [PATCH 7/8] bpf/arm64: add atomic-exchange-and-add operation jerinj
2019-10-18 13:16   ` David Marchand
2019-09-03 10:59 ` [dpdk-dev] [PATCH 8/8] bpf/arm64: add branch operation jerinj
2019-09-24 17:03 ` [dpdk-dev] [PATCH 0/8] eBPF arm64 JIT support Ananyev, Konstantin
2019-10-12 12:22   ` Thomas Monjalon
2019-10-03 12:51 ` Thomas Monjalon
2019-10-03 13:07   ` Jerin Jacob
2019-10-03 15:05     ` Ananyev, Konstantin
2019-10-04  4:55       ` Honnappa Nagarahalli
2019-10-04  9:54         ` Steve Capper
2019-10-04 10:53           ` Thomas Monjalon
2019-10-04 14:09             ` Daniel Borkmann
2019-10-04 14:43               ` Jerin Jacob [this message]
2019-10-05  0:00                 ` Daniel Borkmann
2019-10-05 14:39                   ` Jerin Jacob
2019-10-07 11:57                     ` Ananyev, Konstantin
2019-10-24  4:22                     ` Jerin Jacob
2020-04-06 11:05                 ` Ananyev, Konstantin
2019-10-04 15:39       ` Jerin Jacob
2019-10-07 12:33         ` Thomas Monjalon
2019-10-07 13:00           ` Jerin Jacob
2019-10-07 18:04             ` Thomas Monjalon
2019-10-07 19:29               ` Jerin Jacob
2019-10-07 20:15                 ` Thomas Monjalon
2019-10-08  6:57                   ` Jerin Jacob

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALBAE1PYX4VsuMc5s17opLxgM2uD0JE5NGX-awLqqXJPJ7gffw@mail.gmail.com \
    --to=jerinjacobk@gmail.com \
    --cc=Gavin.Hu@arm.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=Rodolph.Perfetta@arm.com \
    --cc=Steve.Capper@arm.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=john.fastabend@gmail.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=nd@arm.com \
    --cc=quentin.monnet@netronome.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).