Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:

> On Fri, Mar 27, 2020 at 6:10 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
>>
>> > On Fri, Mar 27, 2020 at 3:17 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>> >>
>> >> Andrii Nakryiko <andrii.nakryiko@gmail.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.

Right, great, let's leave this here, then :)

>> > 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 ;)

Well, it was my impression that we were making progress on this; which
is why I got so offended when I suddenly felt myself being accused :/

> But I do assume good faith to the extent possible, which is why we are
> still here at almost 80 emails in.

Great, thank you! And yeah, those emails did stack up, didn't they? I do
think we've made some progress, though, miscommunication and all :)

>> > 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.

Sure, sounds good.

-Toke