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]

Message-ID: <CAM0EoMnHcR9jFVtLt+L1FPRY5BK7_NgH3gsOZxQrXzEkaR1HYQ@mail.gmail.com>
Date:   Fri, 27 Jan 2023 08:33:39 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Jakub Kicinski <kuba@...nel.org>
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 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
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