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: <Y9QXWSaAxl7Is0yz@nanopsycho>
Date:   Fri, 27 Jan 2023 19:26:33 +0100
From:   Jiri Pirko <jiri@...nulli.us>
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,
        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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ