From: Edward Cree <ecree@solarflare.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>,
"John Fastabend" <john.fastabend@gmail.com>,
"Alexei Starovoitov" <alexei.starovoitov@gmail.com>,
"Jesper Dangaard Brouer" <brouer@redhat.com>,
"Lorenz Bauer" <lmb@cloudflare.com>
Cc: Song Liu <songliubraving@fb.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <ast@kernel.org>, Martin Lau <kafai@fb.com>,
Yonghong Song <yhs@fb.com>,
Marek Majkowski <marek@cloudflare.com>,
David Miller <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"bpf@vger.kernel.org" <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next 0/9] xdp: Support multiple programs on a single interface through chain calls
Date: Fri, 4 Oct 2019 11:34:26 +0100 [thread overview]
Message-ID: <68466316-c796-7808-6932-01d9d8c0a40b@solarflare.com> (raw)
In-Reply-To: <87tv8pnd9c.fsf@toke.dk>
On 04/10/2019 09:09, Toke Høiland-Jørgensen wrote:
> Having the mechanism be in-kernel makes solving these problems a lot
> easier, because the kernel can be responsible for state management, and
> it can enforce the chain call execution logic.
I would argue this isn't mechanism, but rather policy, because the
mechanism we already have is sufficient to express the policy.
Enforcement is easily dealt with: you just don't give people the caps/
perms to load XDP programs directly, so the only way they can do it is
via your loader (which you give them a socket or dbus or something to
talk to). (Whereas your chain map doesn't really 'enforce' anything;
anyone who can add themselves to the chain can also remove others.)
Then state inspection happens by querying the loader; if we assume that
the distro provided the central loader, then they can also include the
query in their standard system-dump tools.
Dynamic changes would just mean compiling a new dispatcher, then
atomically replacing the old prog with the new (which we can already
do), since the central loader daemon knows the call graph and can make
changed versions easily.
Centralisation is something that happens normally in userspace; just
count how many daemons your favourite init system runs to administer
system resources and multiplex requests. Probably we'd end up with
one or two standard loaders and interfaces to them.
In any case, it seems like XDP users in userspace still need to
communicate with each other in order to update the chain map (which
seems to rely on knowing where one's own program fits into it); you
suggest they might communicate through the chain map itself, and then
veer off into the weeds of finding race-free ways of doing that. This
seems (to me) needlessly complex.
Incidentally, there's also a performance advantage to an eBPF dispatcher,
because it means the calls to the individual programs can be JITted and
therefore be direct, whereas an in-kernel data-driven dispatcher has to
use indirect calls (*waves at spectre*).
> The fact that Lorenz et al are interested in this feature (even though
> they are essentially already doing what you suggested, by having a
> centralised daemon to manage all XDP programs), tells me that having
> kernel support for this is the right thing to do.
Maybe Lorenz could describe what he sees as the difficulties with the
centralised daemon approach. In what ways is his current "xdpd"
solution unsatisfactory?
-Ed
next prev parent reply other threads:[~2019-10-04 10:34 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-02 13:30 [PATCH bpf-next 0/9] xdp: Support multiple programs on a single interface through chain calls Toke Høiland-Jørgensen
2019-10-02 13:30 ` [PATCH bpf-next 1/9] hashtab: Add new bpf_map_fd_put_value op Toke Høiland-Jørgensen
2019-10-02 13:30 ` [PATCH bpf-next 2/9] xdp: Add new xdp_chain_map type for specifying XDP call sequences Toke Høiland-Jørgensen
2019-10-02 15:50 ` Lorenz Bauer
2019-10-02 18:25 ` Toke Høiland-Jørgensen
2019-10-02 13:30 ` [PATCH bpf-next 3/9] xdp: Support setting and getting device chain map Toke Høiland-Jørgensen
2019-10-02 15:50 ` Lorenz Bauer
2019-10-02 18:32 ` Toke Høiland-Jørgensen
2019-10-02 18:07 ` kbuild test robot
2019-10-02 18:29 ` kbuild test robot
2019-10-02 13:30 ` [PATCH bpf-next 4/9] xdp: Implement chain call logic to support multiple programs on one interface Toke Høiland-Jørgensen
2019-10-02 17:33 ` kbuild test robot
2019-10-02 17:53 ` kbuild test robot
2019-10-02 13:30 ` [PATCH bpf-next 5/9] tools/include/uapi: Add XDP chain map definitions Toke Høiland-Jørgensen
2019-10-02 13:30 ` [PATCH bpf-next 6/9] tools/libbpf_probes: Add support for xdp_chain map type Toke Høiland-Jørgensen
2019-10-02 13:30 ` [PATCH bpf-next 7/9] bpftool: Add definitions " Toke Høiland-Jørgensen
2019-10-02 13:30 ` [PATCH bpf-next 8/9] libbpf: Add support for setting and getting XDP chain maps Toke Høiland-Jørgensen
2019-10-02 13:30 ` [PATCH bpf-next 9/9] selftests: Add tests for XDP chain calls Toke Høiland-Jørgensen
2019-10-02 15:10 ` [PATCH bpf-next 0/9] xdp: Support multiple programs on a single interface through " Alan Maguire
2019-10-02 15:33 ` Toke Høiland-Jørgensen
2019-10-02 16:34 ` John Fastabend
2019-10-02 18:33 ` Toke Høiland-Jørgensen
2019-10-02 20:34 ` John Fastabend
2019-10-03 7:48 ` Toke Høiland-Jørgensen
2019-10-03 10:09 ` Jesper Dangaard Brouer
2019-10-03 19:45 ` John Fastabend
2019-10-02 16:35 ` Lorenz Bauer
2019-10-02 18:54 ` Toke Høiland-Jørgensen
2019-10-02 16:43 ` John Fastabend
2019-10-02 19:09 ` Toke Høiland-Jørgensen
2019-10-02 19:15 ` Daniel Borkmann
2019-10-02 19:29 ` Toke Høiland-Jørgensen
2019-10-02 19:46 ` Alexei Starovoitov
2019-10-03 7:58 ` Toke Høiland-Jørgensen
2019-10-02 18:38 ` Song Liu
2019-10-02 18:54 ` Song Liu
2019-10-02 19:25 ` Toke Høiland-Jørgensen
2019-10-03 8:53 ` Jesper Dangaard Brouer
2019-10-03 14:03 ` Alexei Starovoitov
2019-10-03 14:33 ` Toke Høiland-Jørgensen
2019-10-03 14:53 ` Edward Cree
2019-10-03 18:49 ` Jesper Dangaard Brouer
2019-10-03 19:35 ` John Fastabend
2019-10-04 8:09 ` Toke Høiland-Jørgensen
2019-10-04 10:34 ` Edward Cree [this message]
2019-10-04 15:58 ` Lorenz Bauer
2019-10-07 16:43 ` Edward Cree
2019-10-07 17:12 ` Lorenz Bauer
2019-10-07 19:21 ` Edward Cree
2019-10-07 21:01 ` Alexei Starovoitov
2019-10-02 19:23 ` Toke Høiland-Jørgensen
2019-10-02 19:49 ` Song Liu
2019-10-03 7:59 ` Toke Høiland-Jørgensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=68466316-c796-7808-6932-01d9d8c0a40b@solarflare.com \
--to=ecree@solarflare.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=lmb@cloudflare.com \
--cc=marek@cloudflare.com \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=toke@redhat.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).