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 4A490A32A1 for ; Thu, 24 Oct 2019 06:22:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 383F11C1A2; Thu, 24 Oct 2019 06:22:45 +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 759891C19E for ; Thu, 24 Oct 2019 06:22:43 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id r144so15939551iod.8 for ; Wed, 23 Oct 2019 21:22:43 -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=GvHsYiCkHwfWVrQvijh0UwZhhGlMVnqloC14EY8+yx4=; b=dUUQqxLoaSFfH0ChdsjxTonvDLCIYGn7fXFPDTPLzhsxT1lbqkDcs3OmgMCVYd4wWh vme2IaepXyYbCS1z1Q4K9LUqPY6T7fzqoCs5xVXwOD8tGOXknC2NMsXmTfGAbFqlEQYZ 7dP0UQ3KSbn+ErdRf5T5ih5sS17NKRcDr3oEL9wK/ZNxFfwhejFcLYCl9+XiU4eFyJI0 xW9Dxh9Ft3OYAlC8/nKNf+OSOPjOSJLdDkPcQu89/7EYC1dkuJ8i2A98+8ljVVtqiq4i Szn2je4+V6EDu0Y1XRLUIuESseY3BRQxZRe+CIHJNHPJhyXYPIXnrxSq3ivKleXvmnBk 2CaA== 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=GvHsYiCkHwfWVrQvijh0UwZhhGlMVnqloC14EY8+yx4=; b=La4yN5nPjG0mDFWwNumPU1Vbhn9tD5i72jYo/XMNIEyI6LeJHj8X72R0MCwZIohpj/ uP6aDJA770nxKqHHjE3yRUHUzb/gk43BZw24nnvFXGnyysMMF9VW2nN4UzlV1t4jlY1a /G9/NzJZ5AajhyxmrVkKVlZxTI0/4X217xfA63IPdmjOcVpOxAtmTd6OBkwPsqzPQfXc hpf/7K8A++IfbRQK23fcmgEAwfOV5rbAFJlIw6resctq9+mJMq1L9pPd6TKMd2Tttcdm /26vsAjErEq+SZd5nZ63ckLSw8gih7KFR0uhBnbBQDXkIK+xAIVqdNvTJZipgXLI2Npl b05g== X-Gm-Message-State: APjAAAVbHxviB8KpAWc7TF6oH39iqm1Mqm8sv1OiKbMaj9XwIJCN9GE/ cCgA0ceDumnHCXJfaK3YajSiTEso7d7f2Tlke98= X-Google-Smtp-Source: APXvYqxMXwqcKg8nvnmdC6bpYAKqrsbfjTka/DVqXvtBcVOBFwZaICpn97xXMQrZaii20iJqkuHrVvi5vTSnj+P8wFs= X-Received: by 2002:a5d:8598:: with SMTP id f24mr926917ioj.60.1571890962475; Wed, 23 Oct 2019 21:22:42 -0700 (PDT) MIME-Version: 1.0 References: <20190903105938.33231-1-jerinj@marvell.com> <20191004095455.GA17770@capper-ampere.manchester.arm.com> <2296691.KpWsp5kHI9@xps> <5231837e-3813-0eeb-1c87-5b7072cf8c18@iogearbox.net> In-Reply-To: From: Jerin Jacob Date: Thu, 24 Oct 2019 09:52:26 +0530 Message-ID: To: Daniel Borkmann 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Sat, Oct 5, 2019 at 8:09 PM Jerin Jacob wrote: > > > >> > > >> 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. > > Though, We can not conclude the following non-technical aspects in > this forum like > # Dual license Linux Kernel BPF code as GPL-BSD as a separate library. > # DPDK BPF support for FreeBSD and Windows OS, Treatment for Other OS? > # Need a different treatment for old Linux kernels. > This would call for immediate DPDK release to follow the existing semantics. > > Yes, For the long term, Using the Kernel JITed EBPF program for > userspace will be helpful. At least DPDK can use it in the future. > A couple of other things to consider when someone does this > # https://github.com/iovisor/ubpf can also benefit from this. > # We need to think about how to support tail call in userspace > # It is possible to have burst mode support in userspace as an > improvement (dealing with 4 packets at the time with SIMD). > Dealing SIMD in kernel space will be an issue or dealing with such > improvement in general. > # Kernel verifier and dealing with address has a lot of security > requirements that may not apply for userspace, and therefore some of > the > optimization specific to userspace needs to consider some way > # Based on my understanding the Linux and DPDK JITed code, following > optimizations may need/have a different path > > a) Userspace JIT has to deal with a 64bit address space. Kernel BPF > code can assume the Kernel virtual address space range and optimize. > b) I see, Kernel JIT always makes stack size as non zero even though > BPF applications are not using the stack. I am not sure why it > is that(Could be some security issue). There could be some > optimization not to push the stack pointer in the prologue if EBPF > program does > not use stack > c) In DPDK JIT compiler, In this first pass, we are checking the > actual registers really in use and based on that we are crafting > prologue and > epilogue at runtime to improve the performance. It could be just > implementation detail, but not sure why Linux kernel is not doing such > optimization. Just pinging back to see if anyone interested in the common library. Answers to the above questions and mainly this below thead will make us forward progress for common library if there is still interest in collaboration. http://mails.dpdk.org/archives/dev/2019-October/146063.html