Re: [PATCH net-next RFC 00/20] Introducing P4TC

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 27 Jan 2023 08:33:39 -0500 Jamal Hadi Salim wrote:
> On Thu, Jan 26, 2023 at 6:30 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > On Tue, 24 Jan 2023 12:03:46 -0500 Jamal Hadi Salim wrote:  
> > > There have been many discussions and meetings since about 2015 in regards to
> > > P4 over TC and now that the market has chosen P4 as the datapath specification
> > > lingua franca  
> >
> > Which market?  
> 
> Network programmability involving hardware  - where at minimal the
> specification of the datapath is in P4 and
> often the implementation is. For samples of specification using P4
> (that are public) see for example MS Azure:
> https://github.com/sonic-net/DASH/tree/main/dash-pipeline

That's an IPU thing?

> If you are a vendor and want to sell a NIC in that space, the spec you
> get is in P4.

s/NIC/IPU/ ?

> Your underlying hardware
> doesnt have to be P4 native, but at minimal the abstraction (as we are
> trying to provide with P4TC) has to be
> able to consume the P4 specification.

P4 is certainly an option, especially for specs, but I haven't seen much
adoption myself.
What's the benefit / use case?

> For implementations where P4 is in use, there are many - some public
> others not, sample space:
> https://cloud.google.com/blog/products/gcp/google-cloud-using-p4runtime-to-build-smart-networks

Hyper-scaler proprietary.

> There are NICs and switches which are P4 native in the market.

Link to docs?

> IOW, there is beacoup $ investment in this space that makes it worth pursuing.

Pursuing $ is good! But the community IMO should maximize
a different function.

> TC is the kernel offload mechanism that has gathered deployment
> experience over many years - hence P4TC.

I don't wanna argue. I thought it'd be more fair towards you if I made
my lack of conviction known, rather than sit quiet and ignore it since
it's just an RFC.