As stated a few times, we strongly disagree with the nature of the Nacks from Alexei, Daniel and John. We dont think there is good ground for the Nacks. A brief history on the P4TC patches: We posted V1 in January 2023. The main objection then was that we needed to use eBPF. After some discussion and investigation on our part we found that using kfuncs would satisfy our goals as well as the objections raised. We posted 28 RFC patches looking for feedback from eBPF and other folks with V2 in May 2023 - these patches were not ready but we were nevertheless soliciting for feedback. By Version 7 in October/2023 we removed the RFC tag (meaning we are asking for inclusion). In Version 8 we sent the first 15 patches as series 1(following netdev rules that allow only 15 patches); 5 of these patches are trivial tc core patches. Starting with V8 and upto V14 the releases were mostly suggested changes (much thanks to folks who made suggestions for technical changes) and at one point it was a bug fix for an issue caught by our syzkaller instance. When it seemed like Paolo was heading towards applying series 1 given the feedback, Alexei nacked patch 14 when we released V14, see: https://lore.kernel.org/bpf/20240404122338.372945-5-jhs@xxxxxxxxxxxx/ V15 only change was adding Alexei's nack. V15 was followed by Daniel and then John also nacking the same patch 14. V16's only change was to add these extra Nacks. At that point(v16) i asked for the series to be applied despite the Nacks because, frankly, the Nacks have no merit. Paolo was not comfortable applying patches with Nacks and tried to mediate. In his mediation effort he asked if we could remove eBPF - and our answer was no because after all that time we have become dependent on it and frankly there was no technical reason not to use eBPF. Paolo then asked if we could satisfy one of the points Alexei raised in terms of clearing table entries when an eBPF program was unloaded. We spent a week investigating and came to a conclusion that we could do it as a compromise (even though it is not something fitting to our requirements and there is existing code that we copied from doing exactly what Alexei is objecting to). Alexei rejected this offer. This puts Paolo in a difficult position because it is clear there is no compromise to be had. I feel we are in uncharted teritory. Since we are in a quagmire, I am asking for a third party mediator to review the objections and validate if they have merit. I have created a web page to capture all the objections raised by the 3 gents over a period of time at: https://github.com/p4tc-dev/pushback-patches If any of the 3 people feel i have misrepresented their objections or missed an important detail please let me know and i will fix the page. cheers, jamal
