Date: Tue, 11 Jun 2024 11:10:35 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, deb.chatterjee@...el.com, anjali.singhai@...el.com, 
	namrata.limaye@...el.com, tom@...anda.io, mleitner@...hat.com, 
	Mahesh.Shirshyad@....com, tomasz.osinski@...el.com, jiri@...nulli.us, 
	xiyou.wangcong@...il.com, davem@...emloft.net, edumazet@...gle.com, 
	pabeni@...hat.com, vladbu@...dia.com, horms@...nel.org, khalidm@...dia.com, 
	toke@...hat.com, victor@...atatu.com, pctammela@...atatu.com, 
	Vipin.Jain@....com, dan.daly@...el.com, andy.fingerhut@...il.com, 
	chris.sommers@...sight.com, mattyk@...dia.com, bpf@...r.kernel.org, 
	Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH net-next v16 00/15] Introducing P4TC (series 1)

On Tue, Jun 11, 2024 at 10:21 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> Since the inevitable LWN article has been written, let me put more
> detail into what I already mentioned here:
>
> https://lore.kernel.org/all/20240301090020.7c9ebc1d@kernel.org/
>
> for the benefit of non-networking people.
>
> On Wed, 10 Apr 2024 10:01:26 -0400 Jamal Hadi Salim wrote:
> > P4TC builds on top of many years of Linux TC experiences of a netlink
> > control path interface coupled with a software datapath with an equivalent
> > offloadable hardware datapath.
>
> The point of having SW datapath is to provide a blueprint for the
> behavior. This is completely moot for P4 which comes as a standard.
>
> Besides we already have 5 (or more) flow offloads, we don't need
> a 6th, completely disconnected from the existing ones. Leaving
> users guessing which one to use, and how they interact.
>
> In my opinion, reasonable way to implement programmable parser for

You have mentioned "parser" before - are you referring to the DDP
patches earlier from Intel?
In P4 the parser is just one of the objects.

> Linux is:
>
>  1. User writes their parser in whatever DSL they want
>  2. User compiles the parser in user space
>    2.1 Compiler embeds a representation of the graph in the blob
>  3. User puts the blob in /lib/firmware
>  4. devlink dev $dev reload action parser-fetch $filename
>  5. devlink loads the file, parses it to extract the representation
>     from 2.1, and passes the blob to the driver
>    5.1 driver/fw reinitializes the HW parser
>    5.2 user can inspect the graph by dumping the common representation
>        from 2.1 (via something like devlink dpipe, perhaps)
>  6. The parser tables are annotated with Linux offload targets (routes,
>     classic ntuple, nftables, flower etc.) with some tables being left
>     as "raw"* (* better name would be great)
>  7. ethtool ntuple is extended to support insertion of arbitrary rules
>     into the "raw" tables
>  8. The other tables can only be inserted into using the subsystem they
>     are annotated for
>
> This builds on how some devices _already_ operate. Gives the benefits
> of expressing parser information and ability to insert rules for
> uncommon protocols also for devices which are not programmable.
> And it uses ethtool ntuple, which SW people actually want to use.
>
> Before the tin foil hats gather - we have no use for any of this at
> Meta, I'm not trying to twist the design to fit the use cases of big
> bad hyperscalers.

The scope is much bigger than just parsers though, it is about P4 in
which the parser is but one object.
Limiting what we can do just to fit a narrow definition of "offload"
is not the right direction.
P4 is well understood, hardware exists for P4 and is used to specify
hardware specs and is deployed(See Vipin's comment).


cheers,
jamal

Powered by blists - more mailing lists