From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC8BDC47404 for ; Fri, 4 Oct 2019 14:51:47 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 6B78C2084D for ; Fri, 4 Oct 2019 14:51:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6B78C2084D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=iogearbox.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6D71D1C22B; Fri, 4 Oct 2019 16:51:46 +0200 (CEST) Received: from www62.your-server.de (www62.your-server.de [213.133.104.62]) by dpdk.org (Postfix) with ESMTP id 587931C21C for ; Fri, 4 Oct 2019 16:09:21 +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 1iGOGd-00009H-As; Fri, 04 Oct 2019 16:09:12 +0200 Received: from [2a02:120b:2c12:c120:71a0:62dd:894c:fd0e] (helo=pc-66.home) by sslproxy06.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1iGOGd-000XHt-35; Fri, 04 Oct 2019 16:09:11 +0200 To: Thomas Monjalon , Steve Capper , "Ananyev, Konstantin" , Jerin Jacob Cc: Honnappa Nagarahalli , Rodolph Perfetta , "jerinj@marvell.com" , dev@dpdk.org, "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> From: Daniel Borkmann Message-ID: <5231837e-3813-0eeb-1c87-5b7072cf8c18@iogearbox.net> Date: Fri, 4 Oct 2019 16:09:10 +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: <2296691.KpWsp5kHI9@xps> 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) X-Mailman-Approved-At: Fri, 04 Oct 2019 16:51:45 +0200 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 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. # bpftool prog 2: cgroup_skb tag 7be49e3934a125ba gpl loaded_at 2019-10-03T12:53:11+0200 uid 0 xlated 296B jited 229B memlock 4096B map_ids 2,3 [...] # bpftool prog dump xlated id 2 0: (bf) r6 = r1 1: (69) r7 = *(u16 *)(r6 +192) 2: (b4) w8 = 0 3: (55) if r7 != 0x8 goto pc+14 4: (bf) r1 = r6 5: (b4) w2 = 16 6: (bf) r3 = r10 7: (07) r3 += -4 8: (b4) w4 = 4 9: (85) call bpf_skb_load_bytes#7484768 10: (18) r1 = map[id:2] 12: (bf) r2 = r10 13: (07) r2 += -8 14: (62) *(u32 *)(r2 +0) = 32 15: (85) call trie_lookup_elem#90800 16: (15) if r0 == 0x0 goto pc+1 17: (44) w8 |= 2 18: (55) if r7 != 0xdd86 goto pc+14 19: (bf) r1 = r6 20: (b4) w2 = 24 21: (bf) r3 = r10 22: (07) r3 += -16 23: (b4) w4 = 16 24: (85) call bpf_skb_load_bytes#7484768 25: (18) r1 = map[id:3] 27: (bf) r2 = r10 28: (07) r2 += -20 29: (62) *(u32 *)(r2 +0) = 128 30: (85) call trie_lookup_elem#90800 31: (15) if r0 == 0x0 goto pc+1 32: (44) w8 |= 2 33: (b7) r0 = 1 34: (55) if r8 != 0x2 goto pc+1 35: (b7) r0 = 0 36: (95) exit # bpftool prog dump jited id 2 opcodes 0: push %rbp 55 1: mov %rsp,%rbp 48 89 e5 4: sub $0x40,%rsp 48 81 ec 40 00 00 00 b: sub $0x28,%rbp 48 83 ed 28 f: mov %rbx,0x0(%rbp) 48 89 5d 00 13: mov %r13,0x8(%rbp) 4c 89 6d 08 17: mov %r14,0x10(%rbp) 4c 89 75 10 1b: mov %r15,0x18(%rbp) 4c 89 7d 18 1f: xor %eax,%eax 31 c0 21: mov %rax,0x20(%rbp) 48 89 45 20 25: mov %rdi,%rbx 48 89 fb 28: movzwq 0xc0(%rbx),%r13 4c 0f b7 ab c0 00 00 00 30: xor %r14d,%r14d 45 31 f6 33: cmp $0x8,%r13 49 83 fd 08 37: jne 0x0000000000000079 75 40 39: mov %rbx,%rdi 48 89 df 3c: mov $0x10,%esi be 10 00 00 00 [...] cb: jne 0x00000000000000cf 75 02 cd: xor %eax,%eax 31 c0 cf: mov 0x0(%rbp),%rbx 48 8b 5d 00 d3: mov 0x8(%rbp),%r13 4c 8b 6d 08 d7: mov 0x10(%rbp),%r14 4c 8b 75 10 db: mov 0x18(%rbp),%r15 4c 8b 7d 18 df: add $0x28,%rbp 48 83 c5 28 e3: leaveq c9 e4: retq c3 Thanks, Daniel