Message-ID: <CAOuuhY8+0eMJ_vQW=WgF1dCTLRaN+RARPB9q1RMqvRwv45awzw@mail.gmail.com>
Date: Tue, 11 Jun 2024 09:34:30 -0700
From: Tom Herbert <tom@...anda.io>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org, deb.chatterjee@...el.com, 
	anjali.singhai@...el.com, namrata.limaye@...el.com, 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>, Oz Shlomo <ozsh@...dia.com>
Subject: Re: [PATCH net-next v16 00/15] Introducing P4TC (series 1)

On Tue, Jun 11, 2024 at 8:53 AM Jamal Hadi Salim <jhs@...atatu.com> wrote:
>
> On Tue, Jun 11, 2024 at 11:33 AM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Tue, 11 Jun 2024 11:10:35 -0400 Jamal Hadi Salim wrote:
> > > > 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.
> >
> > For me it's very much not "about P4". I don't care what DSL user prefers
> > and whether the device the offloads targets is built by a P4 vendor.
> >
>
> I think it is an important detail though.
> You wouldnt say PSP shouldnt start small by first taking care of TLS
> or IPSec because it is not the target.
>
> > > Limiting what we can do just to fit a narrow definition of "offload"
> > > is not the right direction.

Jamal,

I think you might be missing Jakub's point. His plan wouldn't narrow
the definition of "offload", but actually would increase applicability
and use cases of offload. The best way to do an offload is allow
flexibility on both sides of the equation: Let the user write their
data path code in whatever language they want, and allow them offload
to arbitrary software or programmable hardware targets.

For example, if a user already has P4 hardware for their high end
server then by all means they should write their datapath in P4. But,
there might also be a user that wants to offload TCP keepalive to a
lower powered CPU on a Smartphone; in this case a simple C program
maybe running in eBPF on the CPU should do the trick-- forcing them to
write their program in P4 or even worse force them to put P4 hardware
into their smartphone is not good. We should be able to define a
common offload infrastructure to be both language and target agnostic
that would handle both these use cases of offload and everything in
between. P4 could certainly be one option for both programming
language and offload target, but it shouldn't be the only option.

Tom

> >
> > This is how Linux development works. You implement small, useful slice
> > which helps the overall project. Then you implement the next, and
> > another.
> >
> > On the technical level, putting the code into devlink rather than TC
> > does not impose any meaningful limitations. But I really don't want
> > you to lift and shift the entire pile of code at once.
> >
>
> Yes, the binary blob is going via devlink or some other scheme.
>
> > > P4 is well understood, hardware exists for P4 and is used to specify
> > > hardware specs and is deployed(See Vipin's comment).
> >
> > "Hardware exists for P4" is about as meaningful as "hardware exists
> > for C++".
>
> We'll have to agree to disagree. Take a look at this for example.
> https://www.servethehome.com/pensando-distributed-services-architecture-smartnic/
>
> cheers,
> jamal

Powered by blists - more mailing lists