From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Edward Cree <ecree@solarflare.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
John Fastabend <john.fastabend@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>, Andrii Nakryiko <andriin@fb.com>,
"David S. Miller" <davem@davemloft.net>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Lorenz Bauer <lmb@cloudflare.com>, Andrey Ignatov <rdna@fb.com>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP
Date: Tue, 31 Mar 2020 13:34:00 +0200 [thread overview]
Message-ID: <87k130iwrb.fsf@toke.dk> (raw)
In-Reply-To: <20200331040112.5tvvubsf6ij4eupb@ast-mbp>
Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
> On Mon, Mar 30, 2020 at 04:41:46PM +0100, Edward Cree wrote:
>> On 29/03/2020 21:23, Andrii Nakryiko wrote:
>> > But you can't say the same about other XDP applications that do not
>> > use libxdp. So will your library come with a huge warning
>> What about a system-wide policy switch to decide whether replacing/
>> removing an XDP program without EXPECTED_FD is allowed? That way
>> the sysadmin gets to choose whether it's the firewall or the packet
>> analyser that breaks, rather than baking a policy into the design.
>> Then libxdp just needs to say in the README "you might want to turn
>> on this switch". Or maybe it defaults to on, and the other program
>> has to talk you into turning it off if it wants to be 'ill-behaved'.
>
> yeah. something like this can work for xdp only, but
> it won't work for tc, since ownership is missing.
> It looks like such policy knob will bere-inventing bpf_link for
> one specific xdp case only because xdp has one program per attachment.
You keep talking about this as though bpf_link was the existing API and
we're discussing adding another, when in reality it's the other way
around.
> Imagine it was easy to come up with sensible policy and allow
> multiple progs in xdp hook.
> How would you implement such policy knob?
> processA attaches prog XDP_A. processB attaches prog XDP-B.
> Unless they start tagging their indivdual programs with BTF tags
> (as Toke is planning to do) there is no way to tell them apart.
> Then processA can iterate all progs in a hook, finds its prog
> based on tag and tell kernel: "find and replace an xdp prog with old_fd
> with new_fd on this ifindex".
> Kinda works, but it doesn't stop processB to accidently detach prog XDP_A
> that was installed by processA.
>
> The kernel job is to share the system resources. Like memory, cpu time.
> The hook is such resource too. The owner concept part of bpf_link
> allows such sharing.
FWIW I actually agree that the bpf_link ownership concept makes sense
for the individual attachments in a multi-prog hook; including for XDP.
And I've started thinking about whether the bpf_link fd can work as the
reference being returned by libxdp after a component program is
attached. I have some reservations, but I'll start a new thread on that
once I'm a bit further along with it...
[...]
> XDP is the hardest, since it does single prog only.
> That's what we're trying to solve with libdispatcher.
> I think if it goes well it can become part of the kernel and kernel
> will do multi prog XDP attach. And all hooks will be symmetrical.
Now *that* I'd like to see! I've said from the beginning that I think
XDP multi-prog should be part of the kernel, so if we can get there via
this detour I'm all for it.
> But looking at the size of this thread and still lots of
> misunderstanding about basic concept like bpf_link I'm not hopeful
> that libdispatcher will ever become part of the kernel.
I don't share your pessimism. If we can stop writing off honest
disagreement about design tradeoffs as just "misunderstanding", I think
we can get there.
-Toke
next prev parent reply other threads:[~2020-03-31 11:34 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-19 13:13 [PATCH bpf-next 0/4] XDP: Support atomic replacement of XDP interface attachments Toke Høiland-Jørgensen
2020-03-19 13:13 ` [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP Toke Høiland-Jørgensen
2020-03-19 22:52 ` Jakub Kicinski
2020-03-20 8:48 ` Toke Høiland-Jørgensen
2020-03-20 17:35 ` Jakub Kicinski
2020-03-20 18:17 ` Toke Høiland-Jørgensen
2020-03-20 18:35 ` Jakub Kicinski
2020-03-20 18:30 ` John Fastabend
2020-03-20 20:24 ` Andrii Nakryiko
2020-03-23 11:24 ` Toke Høiland-Jørgensen
2020-03-23 16:54 ` Jakub Kicinski
2020-03-23 18:14 ` Andrii Nakryiko
2020-03-23 19:23 ` Toke Høiland-Jørgensen
2020-03-24 1:01 ` David Ahern
2020-03-24 4:53 ` Andrii Nakryiko
2020-03-24 20:55 ` David Ahern
2020-03-24 22:56 ` Andrii Nakryiko
2020-03-24 5:00 ` Andrii Nakryiko
2020-03-24 10:57 ` Toke Høiland-Jørgensen
2020-03-24 18:53 ` Jakub Kicinski
2020-03-24 22:30 ` Andrii Nakryiko
2020-03-25 1:25 ` Jakub Kicinski
2020-03-24 19:22 ` John Fastabend
2020-03-25 1:36 ` Alexei Starovoitov
2020-03-25 2:15 ` Jakub Kicinski
2020-03-25 18:06 ` Alexei Starovoitov
2020-03-25 18:20 ` Jakub Kicinski
2020-03-25 19:14 ` Alexei Starovoitov
2020-03-25 10:42 ` Toke Høiland-Jørgensen
2020-03-25 18:11 ` Alexei Starovoitov
2020-03-25 10:30 ` Toke Høiland-Jørgensen
2020-03-25 17:56 ` Alexei Starovoitov
2020-03-24 22:25 ` Andrii Nakryiko
2020-03-25 9:38 ` Toke Høiland-Jørgensen
2020-03-25 17:55 ` Alexei Starovoitov
2020-03-26 0:16 ` Andrii Nakryiko
2020-03-26 5:13 ` Jakub Kicinski
2020-03-26 18:09 ` Andrii Nakryiko
2020-03-26 19:40 ` Alexei Starovoitov
2020-03-26 20:05 ` Edward Cree
2020-03-27 11:09 ` Lorenz Bauer
2020-03-27 23:11 ` Alexei Starovoitov
2020-03-26 10:04 ` Lorenz Bauer
2020-03-26 17:47 ` Jakub Kicinski
2020-03-26 19:45 ` Alexei Starovoitov
2020-03-26 18:18 ` Andrii Nakryiko
2020-03-26 19:53 ` Alexei Starovoitov
2020-03-27 11:11 ` Toke Høiland-Jørgensen
2020-04-02 20:21 ` bpf: ability to attach freplace to multiple parents Alexei Starovoitov
2020-04-02 21:23 ` Toke Høiland-Jørgensen
2020-04-02 21:54 ` Alexei Starovoitov
2020-04-03 8:38 ` Toke Høiland-Jørgensen
2020-04-07 1:44 ` Alexei Starovoitov
2020-04-07 9:20 ` Toke Høiland-Jørgensen
2020-05-12 8:34 ` Toke Høiland-Jørgensen
2020-05-12 9:53 ` Alan Maguire
2020-05-12 13:02 ` Toke Høiland-Jørgensen
2020-05-12 23:18 ` Alexei Starovoitov
2020-05-12 23:06 ` Alexei Starovoitov
2020-05-13 10:25 ` Toke Høiland-Jørgensen
2020-04-02 21:24 ` Andrey Ignatov
2020-04-02 22:01 ` Alexei Starovoitov
2020-03-26 12:35 ` [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP Toke Høiland-Jørgensen
2020-03-26 19:06 ` Andrii Nakryiko
2020-03-27 11:06 ` Lorenz Bauer
2020-03-27 16:12 ` David Ahern
2020-03-27 20:10 ` Andrii Nakryiko
2020-03-27 23:02 ` Alexei Starovoitov
2020-03-30 15:25 ` Edward Cree
2020-03-31 3:43 ` Alexei Starovoitov
2020-03-31 22:05 ` Edward Cree
2020-03-31 22:16 ` Alexei Starovoitov
2020-03-27 19:42 ` Andrii Nakryiko
2020-03-27 19:45 ` Andrii Nakryiko
2020-03-27 23:09 ` Alexei Starovoitov
2020-03-27 11:46 ` Toke Høiland-Jørgensen
2020-03-27 20:07 ` Andrii Nakryiko
2020-03-27 22:16 ` Toke Høiland-Jørgensen
2020-03-27 22:54 ` Andrii Nakryiko
2020-03-28 1:09 ` Toke Høiland-Jørgensen
2020-03-28 1:44 ` Andrii Nakryiko
2020-03-28 19:43 ` Toke Høiland-Jørgensen
2020-03-26 19:58 ` Alexei Starovoitov
2020-03-27 12:06 ` Toke Høiland-Jørgensen
2020-03-27 23:00 ` Alexei Starovoitov
2020-03-28 1:43 ` Toke Høiland-Jørgensen
2020-03-28 2:26 ` Alexei Starovoitov
2020-03-28 19:34 ` Toke Høiland-Jørgensen
2020-03-28 23:35 ` Alexei Starovoitov
2020-03-29 10:39 ` Toke Høiland-Jørgensen
2020-03-29 19:26 ` Alexei Starovoitov
2020-03-30 10:19 ` Toke Høiland-Jørgensen
2020-03-29 20:23 ` Andrii Nakryiko
2020-03-30 13:53 ` Toke Høiland-Jørgensen
2020-03-30 20:17 ` Andrii Nakryiko
2020-03-31 10:13 ` Toke Høiland-Jørgensen
2020-03-31 13:48 ` Daniel Borkmann
2020-03-31 15:00 ` Toke Høiland-Jørgensen
2020-03-31 20:19 ` Andrii Nakryiko
2020-03-31 20:15 ` Andrii Nakryiko
2020-03-30 15:41 ` Edward Cree
2020-03-30 19:13 ` Jakub Kicinski
2020-03-31 4:01 ` Alexei Starovoitov
2020-03-31 11:34 ` Toke Høiland-Jørgensen [this message]
2020-03-31 18:52 ` Alexei Starovoitov
2020-03-20 20:30 ` Daniel Borkmann
2020-03-20 20:40 ` Daniel Borkmann
2020-03-20 21:30 ` Jakub Kicinski
2020-03-20 21:55 ` Daniel Borkmann
2020-03-20 23:35 ` Jakub Kicinski
2020-03-20 20:39 ` Andrii Nakryiko
2020-03-23 11:25 ` Toke Høiland-Jørgensen
2020-03-23 18:07 ` Andrii Nakryiko
2020-03-23 23:54 ` Andrey Ignatov
2020-03-24 10:16 ` Toke Høiland-Jørgensen
2020-03-20 2:13 ` Yonghong Song
2020-03-20 8:48 ` Toke Høiland-Jørgensen
2020-03-19 13:13 ` [PATCH bpf-next 2/4] tools: Add EXPECTED_FD-related definitions in if_link.h Toke Høiland-Jørgensen
2020-03-19 13:13 ` [PATCH bpf-next 3/4] libbpf: Add function to set link XDP fd while specifying old fd Toke Høiland-Jørgensen
2020-03-19 13:13 ` [PATCH bpf-next 4/4] selftests/bpf: Add tests for attaching XDP programs 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=87k130iwrb.fsf@toke.dk \
--to=toke@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=ecree@solarflare.com \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kuba@kernel.org \
--cc=lmb@cloudflare.com \
--cc=netdev@vger.kernel.org \
--cc=rdna@fb.com \
--cc=songliubraving@fb.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).