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 C333BA2F67 for ; Sat, 5 Oct 2019 16:39:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E4DF31C2DD; Sat, 5 Oct 2019 16:39:46 +0200 (CEST) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by dpdk.org (Postfix) with ESMTP id A87871C2DB for ; Sat, 5 Oct 2019 16:39:45 +0200 (CEST) Received: by mail-io1-f65.google.com with SMTP id c6so19618718ioo.13 for ; Sat, 05 Oct 2019 07:39:45 -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=f6HlieX+O/RhqUQcs2Wx86fgYAczjVqGNOoHwHivHlk=; b=uwevwQCpYjKd4pgW1kIlga4PN6URSaR5g7B8+5nJHEV1j4B34J15AEbsUsWl9qmeri /R4Q8ccQdZkqa2wF7mYsu+E2Frhw6fOWT2hC8H9uwUN6FTq6Ah99x27vuJ3Xz1jdJgKk R3093Cy0cYM5j4lxvQwuwZKPwVdkipq5M3N+br+mcopmJonbK5EdVPlU7NEZLD240snA FkmHprQHj8qQ0ihw+sYSvmsr5spepVYWC4MQvmLnNNp+ZR9isHLPiSQApeg3BGCyjkfk jF8tcxpLr7nTrhhatuDRKUZbodDQ6XrPu5yWiWLq196TURfOgVX1tuXabaof7hbegnqS 9iBg== 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=f6HlieX+O/RhqUQcs2Wx86fgYAczjVqGNOoHwHivHlk=; b=R7Ay0VEf9DwYKOTHfNMQfZQ9L/GehGKvu0rxKGEnLCEOuLv7TxtdTZOOUKOMpQMs89 vMc9BumPXVLW2zgChUU+h2D0ufjDWDgpmUqwt0XnXdT5tbgkRryRKhNq5aC/28ncLhV2 JAKXp9ZNgy4xh8ZH5H4SZcciK3o5pyPd8cikz2yLrsliLeVgOu0NJveQYs2f47EanQ9A I7IK9iwtVR+QLbNXNEe1dhy8EkeBFD9Zlpfh5ZlKS2nXoZ5nuNgBxKEX08a2/9J2siCS 2FJLevA7LbS/dQtsOM4dRiqjPfQhSqwDbdkKMn1bO5sWJFVQZDJyNWyKmH8lhcnK8psz QP+Q== X-Gm-Message-State: APjAAAWX4XYdqtdogC21m78v0mpz49Qi4jfxiSw3DxAtRrYjUUdX7+l1 4SMiDqvtmcK1TEGG4FP5KGfjHc1VDT2vTu+W2vM= X-Google-Smtp-Source: APXvYqxCItMSXABrfI5BmRlSWHim3fEgB81k6MBUxJb+eEuOhEJxC8GlccT7Tp92iiYzpTPTRlv5ca0hRyVdFFlIsR8= X-Received: by 2002:a92:1559:: with SMTP id v86mr21849480ilk.130.1570286384735; Sat, 05 Oct 2019 07:39:44 -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: Sat, 5 Oct 2019 20:09:33 +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" > >> > >> 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. Konstantin is the author DPDK EBPF support, I just added arm64 JIT support. Maybe he has more data for this direction. > > > # 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