From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 338D3A2F67 for ; Sat, 5 Oct 2019 02:00:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 283EB1C2BC; Sat, 5 Oct 2019 02:00:23 +0200 (CEST) Received: from www62.your-server.de (www62.your-server.de [213.133.104.62]) by dpdk.org (Postfix) with ESMTP id 3B2DD1C2B9 for ; Sat, 5 Oct 2019 02:00:20 +0200 (CEST) Received: from sslproxy06.your-server.de ([78.46.172.3]) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1iGXUb-0004Ga-5x; Sat, 05 Oct 2019 02:00:13 +0200 Received: from [178.197.248.57] (helo=pc-63.home) by sslproxy06.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1iGXUa-000Pc1-TS; Sat, 05 Oct 2019 02:00:12 +0200 To: Jerin Jacob Cc: Thomas Monjalon , Steve Capper , "Ananyev, Konstantin" , Honnappa Nagarahalli , Rodolph Perfetta , "jerinj@marvell.com" , dpdk-dev , "Gavin Hu (Arm Technology China)" , nd , Alexei Starovoitov , Quentin Monnet , john.fastabend@gmail.com References: <20190903105938.33231-1-jerinj@marvell.com> <20191004095455.GA17770@capper-ampere.manchester.arm.com> <2296691.KpWsp5kHI9@xps> <5231837e-3813-0eeb-1c87-5b7072cf8c18@iogearbox.net> From: Daniel Borkmann Message-ID: Date: Sat, 5 Oct 2019 02:00:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.101.4/25592/Fri Oct 4 10:30:20 2019) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/4/19 4:43 PM, Jerin Jacob wrote: > On Fri, Oct 4, 2019 at 7:39 PM Daniel Borkmann 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 >>>> M: Alexei Starovoitov >>>> M: Zi Shen Lim >>>> 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. Right, definitely makes sense to have consolidation also on this one as well aside from the JITs, and pushing to the kernel and receiving back the JITed image seems quite nice and would be generic to open up many other use cases outside of networking. From app pov, it's just an implementation detail where to get that BPF opcode image from anyway. > 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. Yep, that part would be needed, potentially BTF could be of help here as well for the description of the user space runtime environment like context, helpers etc, so that JIT knows how to handle this. > # DPDK supports FreeBSD and Windows OS as well I'm not too familiar with the state on BPF for the latter two, but afaik FreeBSD at least had some effort to implement a BPF runtime into their kernel as well, so similar interface could be provided, but presumably as starting point vast majority of DPDK users are running Linux underneath anyway? > # Need a different treatment for old Linux kernels. Maybe, though I have little insight from DPDK angle here. Wrt BPF and kernel from what we see major cloud providers usually offer quite recent kernels as well as most mainstream distros that are run there, but again, environments where DPDK is typically deployed may differ (?), so cannot really comment. Thanks, Daniel