Message-ID: <5d9b8ac5655_2a4b2aed075a45b41@john-XPS-13-9370.notmuch>
Date:   Mon, 07 Oct 2019 11:58:13 -0700
From:   John Fastabend <john.fastabend@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Daniel Borkmann <daniel@...earbox.net>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Marek Majkowski <marek@...udflare.com>,
        Lorenz Bauer <lmb@...udflare.com>,
        Alan Maguire <alan.maguire@...cle.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        bpf@...r.kernel.org
Subject: RE: [PATCH bpf-next v3 0/5] xdp: Support multiple programs on a
 single interface through chain calls

Toke Høiland-Jørgensen wrote:
> This series adds support for executing multiple XDP programs on a single
> interface in sequence, through the use of chain calls, as discussed at the Linux
> Plumbers Conference last month:
> 
> https://linuxplumbersconf.org/event/4/contributions/460/
> 

Can we add RFC to the title if we are just iterating through idea-space here.

> # HIGH-LEVEL IDEA
> 
> Since Alexei pointed out some issues with trying to rewrite the eBPF byte code,
> let's try a third approach: We add the ability to chain call programs into the
> eBPF execution core itself, but without rewriting the eBPF byte code.
> 
> As in the previous version, the bpf() syscall gets a couple of new commands
> which takes a pair of BPF program fds and a return code. It will then attach the
> second program to the first one in a structured keyed by return code. When a
> program chain is thus established, the former program will tail call to the
> latter at the end of its execution.
> 
> The actual tail calling is achieved by adding a new flag to struct bpf_prog and
> having BPF_PROG_RUN run the chain call logic if that flag is set. This means
> that if the feature is *not* used, the overhead is a single conditional branch
> (which means I couldn't measure a performance difference, as can be seen in the
> results below).
> 

I still believe user space should be able to link these multiple programs
together as Ed and I were suggesting in the last series. It seems much cleaner
to handle this with calls and linker steps vs adding something on the side to
handle this. Also by doing it by linking your control program can be arbitrary
complex. For example not just taking the output of one program and jumping
to another but doing arbitrary more complex/interesting things. Taking the
input from multiple programs to pick next call for example.

Maybe I missed a point but it seems like the main complaint is tail calls and
regular calls don't mix well. We want to fix this regardless so I don't think
that should be a blocker on using a linking step in user space.

> For this version I kept the load-time flag from the previous version, to avoid
> having to remove the read-only memory protection from the bpf prog. Only
> programs loaded with this flag set can have other programs attached to them for
> chain calls.
> 
> As before, it shouldn't be necessary to set the flag on program load time, but
> rather we should enable the feature when a chain call program is first loaded.
> We could conceivably just remove the RO property from the first page of struct
> bpf_prog and set the flag as needed.
> 
> # PERFORMANCE
> 
> I performed a simple performance test to get an initial feel for the overhead of
> the chain call mechanism. This test consists of running only two programs in
> sequence: One that returns XDP_PASS and another that returns XDP_DROP. I then
> measure the drop PPS performance and compare it to a baseline of just a single
> program that only returns XDP_DROP.
> 
> For comparison, a test case that uses regular eBPF tail calls to sequence two
> programs together is also included.
> 
> | Test case                        | Perf      | Overhead |
> |----------------------------------+-----------+----------|
> | Before patch (XDP DROP program)  | 31.5 Mpps |          |
> | After patch (XDP DROP program)   | 32.0 Mpps |          |
> | XDP chain call (XDP_PASS return) | 28.5 Mpps | 3.8 ns   |
> | XDP chain call (wildcard return) | 28.1 Mpps | 4.3 ns   |
> 
> I consider the "Before patch" and "After patch" to be identical; the .5 Mpps
> difference is within the regular test variance I see between runs. Likewise,
> there is probably no significant difference between hooking the XDP_PASS return
> code and using the wildcard slot.
> 
> # PATCH SET STRUCTURE
> This series is structured as follows:
> 
> - Patch 1: Adds the call chain looping logic
> - Patch 2: Adds the new commands added to the bpf() syscall
> - Patch 3-4: Tools/ update and libbpf syscall wrappers
> - Patch 5: Selftest  with example user space code (a bit hacky still)
> 
> The whole series is also available in my git repo on kernel.org:
> https://git.kernel.org/pub/scm/linux/kernel/git/toke/linux.git/log/?h=xdp-multiprog-03
> 
> Changelog:
> 
> v3:
>   - Keep the UAPI from v2, but change the implementation to hook into
>     BPF_PROG_RUN instead of trying to inject instructions into the eBPF program
>     itself (since that had problems as Alexei pointed out).
> v2:
>   - Completely new approach that integrates chain calls into the core eBPF
>     runtime instead of doing the map XDP-specific thing with a new map from v1.
> 
> ---
> 
> Toke Høiland-Jørgensen (5):
>       bpf: Support chain calling multiple BPF programs after each other
>       bpf: Add support for setting chain call sequence for programs
>       tools: Update bpf.h header for program chain calls
>       libbpf: Add syscall wrappers for BPF_PROG_CHAIN_* commands
>       selftests: Add tests for XDP chain calls
> 
> 
>  include/linux/bpf.h                           |    3 
>  include/linux/filter.h                        |   34 +++
>  include/uapi/linux/bpf.h                      |   16 +
>  kernel/bpf/core.c                             |    6 
>  kernel/bpf/syscall.c                          |   82 ++++++-
>  tools/include/uapi/linux/bpf.h                |   16 +
>  tools/lib/bpf/bpf.c                           |   34 +++
>  tools/lib/bpf/bpf.h                           |    4 
>  tools/lib/bpf/libbpf.map                      |    3 
>  tools/testing/selftests/bpf/.gitignore        |    1 
>  tools/testing/selftests/bpf/Makefile          |    3 
>  tools/testing/selftests/bpf/progs/xdp_dummy.c |    6 
>  tools/testing/selftests/bpf/test_xdp_chain.sh |   77 ++++++
>  tools/testing/selftests/bpf/xdp_chain.c       |  313 +++++++++++++++++++++++++
>  14 files changed, 594 insertions(+), 4 deletions(-)
>  create mode 100755 tools/testing/selftests/bpf/test_xdp_chain.sh
>  create mode 100644 tools/testing/selftests/bpf/xdp_chain.c
> 

Powered by blists - more mailing lists