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

[Dave Taht]

---------- Forwarded message ---------
From: Jamal Hadi Salim <jhs at mojatatu.com>
Date: Fri, Jan 27, 2023 at 6:00 AM
Subject: Re: [PATCH net-next RFC 00/20] Introducing P4TC
To: Jakub Kicinski <kuba at kernel.org>
Cc: <netdev at vger.kernel.org>, <kernel at mojatatu.com>,
<deb.chatterjee at intel.com>, <anjali.singhai at intel.com>,
<namrata.limaye at intel.com>, <khalidm at nvidia.com>, <tom at sipanda.io>,
<pratyush at sipanda.io>, <jiri at resnulli.us>, <xiyou.wangcong at gmail.com>,
<davem at davemloft.net>, <edumazet at google.com>, <pabeni at redhat.com>,
<vladbu at nvidia.com>, <simon.horman at corigine.com>,
<stefanc at marvell.com>, <seong.kim at amd.com>, <mattyk at nvidia.com>,
<dan.daly at intel.com>, <john.andy.fingerhut at intel.com>


On Thu, Jan 26, 2023 at 6:30 PM Jakub Kicinski <kuba at 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
If you are a vendor and want to sell a NIC in that space, the spec you
get is in P4. 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.
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

There are NICs and switches which are P4 native in the market. IOW,
there is beacoup $ investment
in this space that makes it worth pursuing. TC is the kernel offload
mechanism that has gathered deployment
experience over many years - hence P4TC.

> Barely anyone understands the existing TC offloads.

Hyperboles like these are never helpful in a discussion.
TC offloads are deployed today, they work and many folks are actively
working on them.
Are there challenges? yes. For one (and this applies to all kernel
offloads) the process gets
in the way of exposing new features. So there are learnings that we
try to resolve in P4TC.
I'd be curious to hear about your suffering with TC offloads and see
if we can take that
experience and make things better.

>We'd need strong,
> and practical reasons to merge this. Speaking with my "have suffered
> thru the TC offloads working for a vendor" hat on, not the "junior
> maintainer" hat.

P4TC is "standalone" in that it does not affect other TC consumers or
any other subsystems on performance; it is also
sufficiently isolated in that  you can choose to compile it out
altogether and more importantly it comes with committed
support.
And i should emphasize this discussion on getting P4 on TC has been
going on for a few years in the community
culminating with this.

cheers,
jamal


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC