DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Jerin Jacob <jerinjacobk@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	Steve Capper <Steve.Capper@arm.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" <john.fastabend@gmail.com>
Subject: Re: [dpdk-dev] [PATCH 0/8] eBPF arm64 JIT support
Date: Mon, 6 Apr 2020 11:05:40 +0000	[thread overview]
Message-ID: <SN6PR11MB25586E29CE9DE02661DFCD379AC20@SN6PR11MB2558.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CALBAE1PYX4VsuMc5s17opLxgM2uD0JE5NGX-awLqqXJPJ7gffw@mail.gmail.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


  parent reply	other threads:[~2020-04-06 11:05 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
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 [this message]
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=SN6PR11MB25586E29CE9DE02661DFCD379AC20@SN6PR11MB2558.namprd11.prod.outlook.com \
    --to=konstantin.ananyev@intel.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=jerinjacobk@gmail.com \
    --cc=john.fastabend@gmail.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).