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 09:18:15 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     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, 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:  
> > > 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.