Date:   Fri, 27 Mar 2020 18:44:03 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     John Fastabend <john.fastabend@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        "David S. Miller" <davem@...emloft.net>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Lorenz Bauer <lmb@...udflare.com>,
        Andrey Ignatov <rdna@...com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing
 program when attaching XDP

On Fri, Mar 27, 2020 at 6:10 PM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> Andrii Nakryiko <andrii.nakryiko@...il.com> writes:
>
> > On Fri, Mar 27, 2020 at 3:17 PM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
> >>
> >> Andrii Nakryiko <andrii.nakryiko@...il.com> writes:
> >>
> >> > Please stop dodging. Just like with "rest of the kernel", but really
> >> > "just networking" from before.
> >>
> >> Look, if we can't have this conversation without throwing around
> >> accusations of bad faith, I think it is best we just take Ed's advice
> >> and leave it until after the merge window.
> >>
> >
> > Toke, if me pointing out that you are dodging original discussion and
> > pivoting offends you,
>
> It does, because I'm not. See below.
>
> > But if you are still with me, let's look at this particular part of
> > discussion:
> >
> >>> >> For XDP there is already a unique handle, it's just implicit: Each
> >>> >> netdev can have exactly one XDP program loaded. So I don't really see
> >>> >> how bpf_link adds anything, other than another API for the same thing?
> >>> >
> >>> > I certainly failed to explain things clearly if you are still asking
> >>> > this. See point #2, once you attach bpf_link you can't just replace
> >>> > it. This is what XDP doesn't have right now.
> >>>
> >>> Those are two different things, though. I get that #2 is a new
> >>> capability provided by bpf_link, I was just saying #1 isn't (for XDP).
> >>
> >> bpf_link is combination of those different things... Independently
> >> they are either impossible or insufficient. I'm not sure how that
> >> doesn't answer your question:
> >>
> >>> So I don't really see
> >>> how bpf_link adds anything, other than another API for the same thing?
> >>
> >> Please stop dodging. Just like with "rest of the kernel", but really
> >> "just networking" from before.
> >
> > You said "So I don't really see how bpf_link adds anything, other than
> > another API for the same thing?". I explained that bpf_link is not the
> > same thing that exists already, thus it's not another API for the same
> > thing. You picked one property of bpf_link and claimed it's the same
> > as what XDP has right now. "I get that #2 is a new capability provided
> > by bpf_link, I was just saying #1 isn't (for XDP)". So should I read
> > that as if you are agreeing and your original objection is rescinded?
> > If yes, then good, this part is concluded and I'm sorry if I
> > misinterpreted your answer.
>
> Yes, I do believe that was a misinterpretation. Basically, by my
> paraphrasing, our argument goes something like this:
>
> What you said was: "bpf_link adds three things: 1. unique attachment
> identifier, 2. auto-detach and 3. preventing others from overriding it".
>
> And I replied: "1. already exists for XDP, 2. I don't think is the right
> behaviour for XDP, and 3. I don't see the point of - hence I don't
> believe bpf_link adds anything useful for my use case"
>
> I was not trying to cherry-pick any of the properties, and I do
> understand that 2. and 3. are new properties; I just disagree about how
> useful they are (and thus whether they are worth introducing another API
> for).
>

I appreciate you summarizing. It makes everything clearer. I also
don't have much to add after so many rounds.

> > But if not, then you again are picking one properly and just saying
> > "but XDP has it" without considering all of bpf_link properties as a
> > whole. In that case I do think you are arguing not in good faith.
>
> I really don't see how you could read my emails and come to that
> conclusion. But obviously you did, so I'll take that into consideration
> and see if I can express myself clearer in the future. But know this: I
> never deliberately argue in bad faith; so even if it seems like I am,
> please extend me the courtesy of assuming that this is due to either a
> misunderstanding or an honest difference in opinion. I will try to do
> the same for you.

I guess me citing your previous replies and pointing out to
inconsistencies (at least from my interpretation of them) should have
been a signal ;) But I do assume good faith to the extent possible,
which is why we are still here at almost 80 emails in.

>
> > Simple as that. I also hope I don't have to go all the way back to
> > "rest of the kernel", pivoted to "just networking" w.r.t.
> > subsystem-specific configuration/attachment APIs to explain another
> > reference.
>
> Again, I was not trying to "pivot", or attempting to use rhetorical
> tricks to "win" or anything like that. I was making an observation about
> how it's natural that when two subsystems interact, it's quite natural
> that there will be clashes between their different "traditions". And
> that how you view the subsystems' relationship with each other obviously
> affects your opinion of what the right thing to do is in such a
> situation. I never meant to imply anything concrete about BPF in
> anything other than a networking context. And again, I don't understand
> how you could read that out of what I wrote, but I'll take the fact that
> you did into consideration in the future.

Because "rest of the kernel" meant "cgroup subsystem" as well, which
was clearly not true case w.r.t. BPF. But alright, water under the
bridge, let's just not use generalizations too much going forward.

> > P.S. I don't know how merge window has anything to do with this whole
> > discussion, honestly...
>
> Nothing apart from the merge window being a conveniently delimited
> period of time to step away from things and focus on something else.
>
> -Toke
>

Powered by blists - more mailing lists