From: "Toke Høiland-Jørgensen" <toke@redhat•com>
To: Andrii Nakryiko <andrii.nakryiko@gmail•com>
Cc: Andrii Nakryiko <andriin@fb•com>, bpf <bpf@vger•kernel.org>,
Networking <netdev@vger•kernel.org>,
Alexei Starovoitov <ast@fb•com>,
Daniel Borkmann <daniel@iogearbox•net>,
Kernel Team <kernel-team@fb•com>, David Ahern <dsahern@gmail•com>,
Jakub Kicinski <kicinski@fb•com>, Andrey Ignatov <rdna@fb•com>,
Takshak Chahande <ctakshak@fb•com>
Subject: Re: [PATCH bpf-next 2/7] bpf, xdp: add bpf_link-based XDP attachment API
Date: Thu, 16 Jul 2020 12:52:32 +0200 [thread overview]
Message-ID: <87k0z3enpr.fsf@toke.dk> (raw)
In-Reply-To: <CAEf4BzbgPqN8xKX5xpHBRMJSZkhz_BBzBg7r_FPRo=j3ZmLNUQ@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail•com> writes:
> On Wed, Jul 15, 2020 at 8:48 AM Toke Høiland-Jørgensen <toke@redhat•com> wrote:
>>
>> Andrii Nakryiko <andrii.nakryiko@gmail•com> writes:
>>
>> >> Yup, that was helpful, thanks! I think our difference of opinion on this
>> >> stems from the same place as our disagreement about point 2.: You are
>> >> assuming that an application that uses XDP sticks around and holds on to
>> >> its bpf_link, while I'm assuming it doesn't (and so has to rely on
>> >> pinning for any persistence). In the latter case you don't really gain
>> >> much from the bpf_link auto-cleanup, and whether it's a prog fd or a
>> >> link fd you go find in your bpffs doesn't make that much difference...
>> >
>> > Right. But if I had to pick just one implementation (prog fd-based vs
>> > bpf_link), I'd stick with bpf_link because it is flexible enough to
>> > "emulate" prog fd attachment (through BPF FS), but the same isn't true
>> > about prog fd attachment emulating bpf_link. That's it. I really don't
>> > enjoy harping on that point, but it feels to be silently dismissed all
>> > the time based on one particular arrangement for particular existing
>> > XDP flow.
>>
>> It can; kinda. But you introduce a dependency on bpffs that wasn't there
>> before, and you end up with resources that are kept around in the kernel
>> if the interface disappears (because they are still pinned). So I
>> consider it a poor emulation.
>
> Yes, it's not exactly 100% the same semantics.
> It is possible with slight additions to API to support essentially
> exactly the same semantics you want with prog attachment. E.g., we can
> either have a flag at LINK_CREATE time, or a separate command (e.g.,
> LINK_PIN or something), that would mark bpf_link as "sticky", bump
> it's refcnt. What happens then is that even if last FD is closed,
> there is still refcnt 1 there, and then there are two ways to detach
> that link:
>
> 1) interface/cgroup/whatever is destroyed and bpf_link is
> auto-detached. At that point auto-detach handler will see that it's a
> "sticky" bpf_link, will decrement refcnt and subsequently free
> bpf_link kernel object (unless some application still has FD open, of
> course).
>
> 2) a new LINK_DESTROY BPF command will be introduced, which will only
> work with "sticky" bpf_links. It will decrement refcnt and do the same
> stuff as the auto-detach handler does today (so bpf_link->dev = NULL,
> for XDP link).
>
> I don't mind this, as long as this is not a default semantics and
> require conscious opt-in from whoever creates the link.
Now *this* I would like to see! I have the issue with component progs of
the multiprog dispatcher being pinned and making everything stick
around.
[...]
> Sure, thanks, enjoy your vacation! I'll post v3 then with build fixes
> I have so far.
Thanks! :)
-Toke
next prev parent reply other threads:[~2020-07-16 10:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200710224924.4087399-1-andriin@fb.com>
[not found] ` <20200710224924.4087399-3-andriin@fb.com>
2020-07-13 14:19 ` [PATCH bpf-next 2/7] bpf, xdp: add bpf_link-based XDP attachment API David Ahern
2020-07-13 22:33 ` Andrii Nakryiko
2020-07-14 13:57 ` Toke Høiland-Jørgensen
2020-07-14 18:59 ` Andrii Nakryiko
2020-07-14 20:12 ` Toke Høiland-Jørgensen
2020-07-14 20:37 ` Andrii Nakryiko
2020-07-14 21:41 ` Toke Høiland-Jørgensen
2020-07-14 22:26 ` Andrii Nakryiko
2020-07-15 15:48 ` Toke Høiland-Jørgensen
2020-07-15 20:54 ` Andrii Nakryiko
2020-07-16 10:52 ` Toke Høiland-Jørgensen [this message]
2020-07-22 6:45 ` Andrii Nakryiko
[not found] ` <20200710224924.4087399-5-andriin@fb.com>
2020-07-13 14:32 ` [PATCH bpf-next 4/7] bpf: implement BPF XDP link-specific introspection APIs David Ahern
2020-07-13 22:41 ` Andrii Nakryiko
2020-07-13 5:12 [PATCH bpf-next 0/7] BPF XDP link Andrii Nakryiko
2020-07-13 5:12 ` [PATCH bpf-next 2/7] bpf, xdp: add bpf_link-based XDP attachment API Andrii Nakryiko
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=87k0z3enpr.fsf@toke.dk \
--to=toke@redhat$(echo .)com \
--cc=andrii.nakryiko@gmail$(echo .)com \
--cc=andriin@fb$(echo .)com \
--cc=ast@fb$(echo .)com \
--cc=bpf@vger$(echo .)kernel.org \
--cc=ctakshak@fb$(echo .)com \
--cc=daniel@iogearbox$(echo .)net \
--cc=dsahern@gmail$(echo .)com \
--cc=kernel-team@fb$(echo .)com \
--cc=kicinski@fb$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=rdna@fb$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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