On 2/28/24 9:11 AM, John Fastabend wrote:
- The kfuncs are mostly duplicates of map ops we already have in BPF API.
The motivation by my read is to use netlink instead of bpf commands. I
I also have similar thought on the kfuncs (create/update/delete) which is mostly
bpf map ops. It could have one single kfunc to allocate a kernel specific p4
entry/object and then store that in a bpf map. With the bpf_rbtree, bpf_list,
and other recent advancements, it should be able to describe them in a bpf map.
The reply in v9 was that the p4 table will also be used in the future HW
piece/driver but the HW piece is not ready yet, bpf is the only consumer of the
kernel p4 table now and this makes mimicking the bpf map api to kfuncs not
convincing. bpf "tc / xdp" program uses netlink to attach/detach and the policy
also stays in the bpf map.
When there is a HW piece that consumes the p4 table, that will be a better time
to discuss the kfunc interface.
don't agree with this, optimizing for some low level debug a developer
uses is the wrong design space. Actual users should not be deploying
this via ssh into boxes. The workflow will not scale and really we need
tooling and infra to land P4 programs across the network. This is orders
of more pain if its an endpoint solution and not a middlebox/switch
solution. As a switch solution I don't see how p4tc sw scales to even TOR
packet rates. So you need tooling on top and user interact with the
tooling not the Linux widget/debugger at the bottom.
