On Fri, Apr 5, 2024 at 11:51 AM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: > > On 4/5/24 1:16 AM, Jamal Hadi Salim wrote: > > On Thu, Apr 4, 2024 at 7:05 PM Alexei Starovoitov > > <alexei.starovoitov@xxxxxxxxx> wrote: > >> On Thu, Apr 4, 2024 at 3:59 PM Jamal Hadi Salim <jhs@xxxxxxxxxxxx> wrote: > >>> > >>> We will use ebpf/xdp/kfuncs whenever they make sense to us. > >> > >> In such case my Nack stands even if you drop this patch. > > > > We are not changing any ebpf code. I must have missed the memo that > > stated you can control how people write or use ebpf. > > The situation is this: Anybody can write kfuncs today. They can put > > them in kernel modules - i am sure you designed it with that intent. > > So what exactly are you objecting to that is ebpf related here? > > To be honest, this entire patchset is questionable from a design pov for > the many reasons stated by various folks (including tc co-maintainers) in > all the earlier discussions, but related to the BPF bits if someone else > were trying to propose an interface on kfuncs which replicate to a larger > extend BPF map APIs, the feedback would be similarly in that this should > be attempted to generalize instead so that this is useful as a building > block, esp given the goal is on SW datapath and not offloads, and the > context specific pieces would reside in the p4tc code. "questionable from a design pov" is the crux of the back and forth. You have to live in a world where other people have different design Povs, different use cases. You are imposing on us how it should be done and according to you guys just because it runs in tc it is inferior. In open source you work on your itches - many use cases and many designs. Given history on how far we bent over to try and reach a compromise i have concluded we'll never satisfy you. 100% of the code is in the tc domain. It is touching zero of the ebpf code. We are using kfuncs the way they are intended. You are not going to stop people using kfuncs the way we did. Giving us advice on how to better kfuncs is reasonable. Martin did that and we fixed those issues. Trying to dictate whether we can use kfuncs or not is crossing the line in particular given that you have said many times that kfuncs dont even have to be even posted on the bpf mailing list. And i am not going to relitigate some of the statements you made above that we have rehashed many times. Read the cover letter. cheers, jamal
