On Thu, Apr 11, 2024 at 10:07 AM Paolo Abeni <pabeni@xxxxxxxxxx> wrote: > > On Wed, 2024-04-10 at 10:01 -0400, Jamal Hadi Salim wrote: > > The only change that v16 makes is to add a nack to patch 14 on kfuncs > > from Daniel and John. We strongly disagree with the nack; unfortunately I > > have to rehash whats already in the cover letter and has been discussed over > > and over and over again: > > I feel bad asking, but I have to, since all options I have here are > IMHO quite sub-optimal. > > How bad would be dropping patch 14 and reworking the rest with > alternative s/w datapath? (I guess restoring it from oldest revision of > this series). We want to keep using ebpf for the s/w datapath if that is not clear by now. I do not understand the obstructionism tbh. Are users allowed to use kfuncs as part of infra or not? My understanding is yes. This community is getting too political and my worry is that we have corporatism creeping in like it is in standards bodies. We started by not using ebpf. The same people who are objecting now went up in arms and insisted we use ebpf. As a member of this community, my motivation was to meet them in the middle by compromising. We invested another year to move to that middle ground. Now they are insisting we do not use ebpf because they dont like our design or how we are using ebpf or maybe it's not a use case they have any need for or some other politics. I lost track of the moving goal posts. Open source is about solving your itch. This code is entirely on TC, zero code changed in ebpf core. The new goalpost is based on emotional outrage over use of functions. The whole thing is getting extremely toxic. cheers, jamal
