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

From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Martin KaFai Lau <martin.lau@linux.dev>
Cc: John Fastabend <john.fastabend@gmail.com>,
	deb.chatterjee@intel.com,  anjali.singhai@intel.com,
	namrata.limaye@intel.com, tom@sipanda.io,  mleitner@redhat.com,
	Mahesh.Shirshyad@amd.com, Vipin.Jain@amd.com,
	 tomasz.osinski@intel.com, jiri@resnulli.us,
	xiyou.wangcong@gmail.com,  davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	 vladbu@nvidia.com, horms@kernel.org, khalidm@nvidia.com,
	toke@redhat.com,  daniel@iogearbox.net, victor@mojatatu.com,
	pctammela@mojatatu.com,  dan.daly@intel.com,
	andy.fingerhut@gmail.com, chris.sommers@keysight.com,
	 mattyk@nvidia.com, bpf@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH net-next v12 00/15] Introducing P4TC (series 1)
Date: Fri, 1 Mar 2024 07:36:13 -0500	[thread overview]
Message-ID: <CAM0EoMmw25Kye4TTdFMAe8w-VgH++NkbNHcZcsfKR3diS28fSg@mail.gmail.com> (raw)
In-Reply-To: <332c7a04-edc8-40bd-9e8f-69c5d297e845@linux.dev>

On Fri, Mar 1, 2024 at 2:02 AM Martin KaFai Lau <martin.lau@linux.dev> wrote:
>
> 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.
>

It's a lot more complex than just attaching/detaching. Our control
plane uses netlink (regardless of whether it is offloaded or not) for
all object controls (not just table entries) for the many reasons that
have been stated in the cover letters since the beginning. I
unfortunately took out some of the text after v10 to try and shorten
the text. I will be adding it back. If you cant find it i could
cutnpaste and send privately.

cheers,
jamal

> 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.
>