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