Date:   Mon, 09 Mar 2020 12:41:14 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 0/3] Introduce pinnable bpf_link kernel abstraction

Jakub Kicinski <kuba@...nel.org> writes:

> On Thu, 05 Mar 2020 12:05:23 +0100 Toke Høiland-Jørgensen wrote:
>> Jakub Kicinski <kuba@...nel.org> writes:
>> > On Wed, 4 Mar 2020 17:07:08 -0800, Alexei Starovoitov wrote:  
>> >> > Maybe also the thief should not have CAP_ADMIN in the first place?
>> >> > And ask a daemon to perform its actions..    
>> >> 
>> >> a daemon idea keeps coming back in circles.
>> >> With FD-based kprobe/uprobe/tracepoint/fexit/fentry that problem is gone,
>> >> but xdp, tc, cgroup still don't have the owner concept.
>> >> Some people argued that these three need three separate daemons.
>> >> Especially since cgroups are mainly managed by systemd plus container
>> >> manager it's quite different from networking (xdp, tc) where something
>> >> like 'networkd' might makes sense.
>> >> But if you take this line of thought all the ways systemd should be that
>> >> single daemon to coordinate attaching to xdp, tc, cgroup because
>> >> in many cases cgroup and tc progs have to coordinate the work.  
>> >
>> > The feature creep could happen, but Toke's proposal has a fairly simple
>> > feature set, which should be easy to cover by a stand alone daemon.
>> >
>> > Toke, I saw that in the library discussion there was no mention of 
>> > a daemon, what makes a daemon solution unsuitable?  
>> 
>> Quoting from the last discussion[0]:
>> 
>> > - Introducing a new, separate code base that we'll have to write, support
>> >   and manage updates to.
>> >
>> > - Add a new dependency to using XDP (now you not only need the kernel
>> >   and libraries, you'll also need the daemon).
>> >
>> > - Have to duplicate or wrap functionality currently found in the kernel;
>> >   at least:
>> >   
>> >     - Keeping track of which XDP programs are loaded and attached to
>> >       each interface (as well as the "new state" of their attachment
>> >       order).
>> >
>> >     - Some kind of interface with the verifier; if an app does
>> >       xdpd_rpc_load(prog), how is the verifier result going to get back
>> >       to the caller?
>> >
>> > - Have to deal with state synchronisation issues (how does xdpd handle
>> >   kernel state changing from underneath it?).
>> > 
>> > While these are issues that are (probably) all solvable, I think the
>> > cost of solving them is far higher than putting the support into the
>> > kernel. Which is why I think kernel support is the best solution :)  
>> 
>> The context was slightly different, since this was before we had
>> freplace support in the kernel. But apart from the point about the
>> verifier, I think the arguments still stand. In fact, now that we have
>> that, we don't even need userspace linking, so basically a daemon's only
>> task would be to arbitrate access to the XDP hook? In my book,
>> arbitrating access to resources is what the kernel is all about...
>
> You said that like the library doesn't arbitrate access and manage
> resources.. It does exactly the same work the daemon would do.

Sure, the logic is in the library, but the state (which programs are
loaded) and synchronisation primitives (atomic replace of attached
program) are provided by the kernel. 

> Daemon just trades off the complexity of making calls for the
> complexity of the system and serializing/de-serializing the state.

What state are we serialising? I'm not sure I would consider just
pinning things in bpffs as "state serialisation"?

-Toke

Powered by blists - more mailing lists