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