On Fri, Mar 27, 2020 at 6:10 PM Toke Høiland-Jørgensen [off-list ref] wrote:

Andrii Nakryiko [off-list ref] writes:

quoted

On Fri, Mar 27, 2020 at 3:17 PM Toke Høiland-Jørgensen [off-list ref] wrote:

quoted

Andrii Nakryiko [off-list ref] writes:

quoted

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.

quoted

But if you are still with me, let's look at this particular part of
discussion:

quoted

quoted

quoted

quoted

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:

quoted

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.

quoted

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.

quoted

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.

quoted

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