Subject: Re: [PATCH net-next v12 00/15] Introducing P4TC (series 1)

From: Martin KaFai Lau <[email-masked]>
Date: Thu, 29 Feb 2024 23:02:31 -0800

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.