From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5931FA2F67 for <public@inbox.dpdk.org>; Fri, 4 Oct 2019 16:43:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9ACF21C22A; Fri, 4 Oct 2019 16:43:14 +0200 (CEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id F01DE1C227 for <dev@dpdk.org>; Fri, 4 Oct 2019 16:43:12 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id q1so14140066ion.1 for <dev@dpdk.org>; Fri, 04 Oct 2019 07:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q6hZjlV7fGtIDm2IH8w+JDKvOW6Dz9EZ2o82eZfdo5Q=; b=R3HsPc3VQ44rLv4jX2PwU5tgrkXrWEBTKLKYZIWS4zKGcr7Q90YFLDD8kHkPdKZfL/ a8ZDxl7yRsTLfKKQsHF4c4t3uf+WUoW246wiR8HGjgh4GxNx2O7v2A0dFpFgTr/vQGXn QbODvUE2PnttD+m0+UpYIF7W/jfGWt4PnHWj8G6kGe9esfopCFKpT3Ca+EUitByfZiYi f/muPj0Z6nilVRLM/9QIyjOitvOGtIeKKvKOsN4nBc20asW3e8o0wSP9Ws+iFnBnWHZv u4NNV/7tg/t0yOI8CNIRscJq4hc9CUBfthfnkfAugN2c5ACv64KRQG0o4cFYiJaFevHX KUDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q6hZjlV7fGtIDm2IH8w+JDKvOW6Dz9EZ2o82eZfdo5Q=; b=S1vi2Ze61qeApdKycSw1otbAbykBYnqpaiknO/a/Xhi2xYyRIcGuvOWMmN5dNtB+H/ qqnMHNZfh4au9JFbuY8taOyHvbm4e2Nt7i8b91QAdH/j0Qm6PgdxrL+8hJD4My0q/rGM NPYC8Yp2STa+tX2QtLqBXOIHHS+a9FUrWn1Z4NsJRP80A4x8OTN/Mnfzz9NGYoVXR1kS 7QFSAQMkyUba5oNI4RaShl5kkOdnoWDkAzDYEUASD1vXTmYq6+AGK67IF3EHUPR0ASjd bVDfhwM6Sq3MWlaQcBKMYeSRhSIFUsaYhVqNrMB1sVP5QCQ8rd/hmmmXnpfljhTBF+DU WL7w== X-Gm-Message-State: APjAAAUsBUu0kHJ7xzenss9CERjNP1egjoguA4/kxFUP0Pt6s60mLgX3 iv2XEYP0XgrB3cFJBuxtL4BGSQxHDSJTdARvQdQ= X-Google-Smtp-Source: APXvYqynuVQJPtYbcJO7AbNQFj8Q1CfsauRUuYfOLk1QjfbjWuz4HBpe2eMpNw/pjmF78jcDVC23R5mda97kbMB4ldA= X-Received: by 2002:a92:de42:: with SMTP id e2mr103317ilr.271.1570200191908; Fri, 04 Oct 2019 07:43:11 -0700 (PDT) MIME-Version: 1.0 References: <20190903105938.33231-1-jerinj@marvell.com> <VE1PR08MB51490FB28EC8C05F0EA46AAF989E0@VE1PR08MB5149.eurprd08.prod.outlook.com> <20191004095455.GA17770@capper-ampere.manchester.arm.com> <2296691.KpWsp5kHI9@xps> <5231837e-3813-0eeb-1c87-5b7072cf8c18@iogearbox.net> In-Reply-To: <5231837e-3813-0eeb-1c87-5b7072cf8c18@iogearbox.net> From: Jerin Jacob <jerinjacobk@gmail.com> Date: Fri, 4 Oct 2019 20:13:01 +0530 Message-ID: <CALBAE1PYX4VsuMc5s17opLxgM2uD0JE5NGX-awLqqXJPJ7gffw@mail.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 Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 0/8] eBPF arm64 JIT support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> 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. > >