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 15:04:31 -0500
From:   Jamal Hadi Salim <hadi@...atatu.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        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,
        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 1:26 PM Jiri Pirko <jiri@...nulli.us> wrote:
>
> Fri, Jan 27, 2023 at 12:30:22AM CET, 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?
> >
> >Barely anyone understands the existing TC offloads. 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.
>
> You talk about offload, yet I don't see any offload code in this RFC.
> It's pure sw implementation.
>
> But speaking about offload, how exactly do you plan to offload this
> Jamal? AFAIK there is some HW-specific compiler magic needed to generate
> HW acceptable blob. How exactly do you plan to deliver it to the driver?
> If HW offload offload is the motivation for this RFC work and we cannot
> pass the TC in kernel objects to drivers, I fail to see why exactly do
> you need the SW implementation...

Our rule in TC is: _if you want to offload using TC you must have a
s/w equivalent_.
We enforced this rule multiple times (as you know).
P4TC has a sw equivalent to whatever the hardware would do. We are pushing that
first. Regardless, it has value on its own merit:
I can run P4 equivalent in s/w in a scriptable (as in no compilation
in the same spirit as u32 and pedit),
by programming the kernel datapath without changing any kernel code.

To answer your question in regards to what the interfaces "P4
speaking" hardware or drivers
are going to be programmed, there are discussions going on right now:
There is a strong
leaning towards devlink for the hardware side loading.... The idea
from the driver side is to
reuse the tc ndos.
We have biweekly meetings which are open. We do have Nvidia folks, but
would be great if
we can have you there. Let me find the link and send it to you.
Do note however, our goal is to get s/w first as per tradition of
other offloads with TC .

cheers,
jamal