Date:   Sun, 17 Dec 2017 20:38:52 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Alexei Starovoitov <ast@...nel.org>,
        "David S . Miller" <davem@...emloft.net>
Cc:     John Fastabend <john.fastabend@...il.com>,
        Edward Cree <ecree@...arflare.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        netdev@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCH bpf-next 00/13] bpf: introduce function calls

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!

Powered by blists - more mailing lists