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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 27 Jan 2023 14:42:48 -0500
From:   Jamal Hadi Salim <hadi@...atatu.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>, netdev@...r.kernel.org,
        kernel@...atatu.com, deb.chatterjee@...el.com,
        anjali.singhai@...el.com, namrata.limaye@...el.com,
        khalidm@...dia.com, tom@...anda.io, pratyush@...anda.io,
        jiri@...nulli.us, xiyou.wangcong@...il.com, davem@...emloft.net,
        edumazet@...gle.com, pabeni@...hat.com, vladbu@...dia.com,
        simon.horman@...igine.com, stefanc@...vell.com, seong.kim@....com,
        mattyk@...dia.com, dan.daly@...el.com,
        john.andy.fingerhut@...el.com
Subject: Re: [PATCH net-next RFC 00/20] Introducing P4TC

On Fri, Jan 27, 2023 at 12:18 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> 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@...nel.org> wrote:
> > > On Tue, 24 Jan 2023 12:03:46 -0500 Jamal Hadi Salim wrote:

[..]
> > 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?
>

Yes, DASH is xPU. But the whole Sonic/SAI thing includes switches and P4 plays
a role there.

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

I do believe that one can write a P4 program to express things a
regular NIC could express
that may be harder to expose with current interfaces.

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

The xPU market outside of hyper-scalers is emerging now. Hyperscalers
looking at xPUs
are looking at P4 as the datapath language - that sets the trend
forward to large enterprises.
That's my experience.
Some of the vendors on the Cc should be able to point to adoption.
Anjali? Matty?

> What's the benefit / use case?

Of P4 or xPUs?
Unified approach to standardize how a datapath is defined is a value for P4.
Providing a singular abstraction via the kernel (as opposed to every
vendor pitching
their API) is what the kernel brings.

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

The control abstraction (P4 runtime) is certainly not proprietary.
The datapath that is targetted by the runtime is.
Hopefully we can fix that with P4TC.
The majority of the discussions i have with some of the folks who do
kernel bypass have one theme in common:
The kernel process is just too long. Trying to add one feature to
flower could take anywhere from 6 months to 3
years to finally show up in some supported distro. With P4TC we are
taking the approach of scriptability to allow
for speacilized datapaths (which P4 excels in). The google datapath
maybe proprietary while their hardware may
even(or not) be using native P4 - but the important detail is we have
_a way_ to abstract those datapaths.

> > There are NICs and switches which are P4 native in the market.
>
> Link to docs?
>

Off top of my head Intel Mount Evans, Pensando, Xilinx FPGAs, etc. The
point is to bring them together
under the linux umbrella.

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

While I agree $ is not the primary motivator it is a factor, it is a
good indicator. No different than the network stack
being tweaked to do certain things that certain hyperscalers need
because they invest $.
I have no problems with a large harmonious tent.

cheers,
jamal

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