From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
John Fastabend <john.fastabend@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
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>,
David Ahern <dsahern@gmail.com>
Subject: Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP
Date: Tue, 31 Mar 2020 13:19:10 -0700 [thread overview]
Message-ID: <CAEf4BzaQANTPcWQu=0m=K9=CEFboBLN36a0B2XeX+qjuPdQ=8w@mail.gmail.com> (raw)
In-Reply-To: <87blocin7p.fsf@toke.dk>
On Tue, Mar 31, 2020 at 8:00 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Daniel Borkmann <daniel@iogearbox.net> writes:
>
> > On 3/31/20 12:13 PM, Toke Høiland-Jørgensen wrote:
> >> Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> >>
> >>>>> So you install your libxdp-based firewalls and are happy. Then you
> >>>>> decide to install this awesome packet analyzer, which doesn't know
> >>>>> about libxdp yet. Suddenly, you get all packets analyzer, but no more
> >>>>> firewall, until users somehow notices that it's gone. Or firewall
> >>>>> periodically checks that it's still runinng. Both not great, IMO, but
> >>>>> might be acceptable for some users, I guess. But imagine all the
> >>>>> confusion for user, especially if he doesn't give a damn about XDP and
> >>>>> other buzzwords, but only needs a reliable firewall :)
> >>>>
> >>>> Yes, whereas if the firewall is using bpf_link, then the packet analyser
> >>>> will be locked out and can't do its thing. Either way you end up with a
> >>>> broken application; it's just moving the breakage. In the case of
> >>>
> >>> Hm... In one case firewall installation reported success and stopped
> >>> working afterwards with no notification and user having no clue. In
> >>> another, packet analyzer refused to start and reported error to user.
> >>> Let's agree to disagree that those are not at all equivalent. To me
> >>> silent failure is so much worse, than application failing to start in
> >>> the first place.
> >
> > I sort of agree with both of you that either case is not great. The silent
> > override we currently have is not great since it can be evicted at any time
> > but also bpf_link to lock-out other programs at XDP layer is not great either
> > since there is also huge potential to break existing programs. It's probably
> > best to discuss on an actual proposal to see the concrete semantics, but my
> > concerns, assuming I didn't misunderstand or got confused on something along
> > the way (if so, please let me know), currently are:
>
> I think you're summarising the issues well, with perhaps one thing
> missing: The goal is to enable multi-prog execution, i.e., execute two
> programs in sequence. So, when things work correctly the flow should be:
>
> App1, loading prog1:
> - get current program from $IFACE
> - current program is NULL:
> -> build dispatcher(prog1)
> -> load dispatcher onto $IFACE with UPDATE_IF_NOEXIST flag
> -> success
>
> Then, app2 loading prog2:
> - get current program from $IFACE
> - current program is dispatcher(prog1):
> -> build new dispatcher(prog1,prog2)
> -> atomically replace old dispatcher with new one
> -> success
>
> As long as app1 and app2 agree on what a dispatcher looks like, and how
> to update it, they can cooperatively install themselves in the chain, as
> long as there's a way to resolve the race between reading and updating
> the state in the kernel.
>
> However, if they *don't* agree on how to build the dispatcher and run in
> sequence, they are fundamentally incompatible. Which also means that
> multi-prog operation is going to be incompatible with any application
> that was written before it was implemented. The only way to avoid that
> is to provide the multi-prog support in the kernel, in a way that is
> compatible with the old API. I'm not sure if this is even possible; but
> I certainly got a very emphatic NACK on any attempt to implement the
> support in the kernel when I posted my initial patch back in the fall.
>
> Also, to your point about needing a specific library: I've been saying
> "using the same library" because I think that is the most likely way to
> get applications to agree. But really, what's needed is more like a
> protocol; there could in theory be several independent implementations
> that interoperate. However, I don't see a way to make things compatible
> with applications that don't follow that protocol; we only get to pick
> the failure mode (and those failure modes I think you summarised quite
> well).
Well, for once we agree with Toke in this thread (regarding last two
paragraphs) :)
>
> -Toke
>
next prev parent reply other threads:[~2020-03-31 20:19 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 [this message]
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
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='CAEf4BzaQANTPcWQu=0m=K9=CEFboBLN36a0B2XeX+qjuPdQ=8w@mail.gmail.com' \
--to=andrii.nakryiko@gmail.com \
--cc=alexei.starovoitov@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=dsahern@gmail.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=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).