From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Borkmann Subject: Re: [PATCH bpf-next 00/13] bpf: introduce function calls Date: Sun, 17 Dec 2017 20:38:52 +0100 Message-ID: <4544243e-79d1-b9ac-de3b-e062a3663d96@iogearbox.net> References: <20171215015517.409513-1-ast@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: John Fastabend , Edward Cree , Jakub Kicinski , netdev@vger.kernel.org, kernel-team@fb.com To: Alexei Starovoitov , "David S . Miller" Return-path: Received: from www62.your-server.de ([213.133.104.62]:56609 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754757AbdLQTjB (ORCPT ); Sun, 17 Dec 2017 14:39:01 -0500 In-Reply-To: <20171215015517.409513-1-ast@kernel.org> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 12/15/2017 02:55 AM, Alexei Starovoitov wrote: > First of all huge thank you to Daniel, John, Jakub, Edward and others who > reviewed multiple iterations of this patch set over the last many months > and to Dave and others who gave critical feedback during netconf/netdev. > > The patch is solid enough and we thought through numerous corner cases, > but it's not the end. More followups with code reorg and features to follow. > > TLDR: Allow arbitrary function calls from bpf function to another bpf function. > > Since the beginning of bpf all bpf programs were represented as a single function > and program authors were forced to use always_inline for all functions > in their C code. That was causing llvm to unnecessary inflate the code size > and forcing developers to move code to header files with little code reuse. > > With a bit of additional complexity teach verifier to recognize > arbitrary function calls from one bpf function to another as long as > all of functions are presented to the verifier as a single bpf program. > Extended program layout: > .. > r1 = .. // arg1 > r2 = .. // arg2 > call pc+1 // function call pc-relative > exit > .. = r1 // access arg1 > .. = r2 // access arg2 > .. > call pc+20 // second level of function call > ... > > It allows for better optimized code and finally allows to introduce > the core bpf libraries that can be reused in different projects, > since programs are no longer limited by single elf file. > With function calls bpf can be compiled into multiple .o files. > > This patch is the first step. It detects programs that contain > multiple functions and checks that calls between them are valid. > It splits the sequence of bpf instructions (one program) into a set > of bpf functions that call each other. Calls to only known > functions are allowed. Since all functions are presented to > the verifier at once conceptually it is 'static linking'. > > Future plans: > - introduce BPF_PROG_TYPE_LIBRARY and allow a set of bpf functions > to be loaded into the kernel that can be later linked to other > programs with concrete program types. Aka 'dynamic linking'. > > - introduce function pointer type and indirect calls to allow > bpf functions call other dynamically loaded bpf functions while > the caller bpf function is already executing. Aka 'runtime linking'. > This will be more generic and more flexible alternative > to bpf_tail_calls. > > FAQ: > Q: Interpreter and JIT changes mean that new instruction is introduced ? > A: No. The call instruction technically stays the same. Now it can call > both kernel helpers and other bpf functions. > Calling convention stays the same as well. > From uapi point of view the call insn got new 'relocation' BPF_PSEUDO_CALL > similar to BPF_PSEUDO_MAP_FD 'relocation' of bpf_ldimm64 insn. > > Q: What had to change on LLVM side? > A: Trivial LLVM patch to allow calls was applied to upcoming 6.0 release: > https://reviews.llvm.org/rL318614 > with few bugfixes as well. > Make sure to build the latest llvm to have bpf_call support. > > More details in the patches. Series applied to bpf-next, thanks Alexei!