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.
