[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dbdc320e-bd4a-eb49-5c6d-8f861602046f@intel.com>
Date: Fri, 25 Aug 2023 12:52:27 +0200
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: Junfeng Guo <junfeng.guo@...el.com>, <anthony.l.nguyen@...el.com>,
<jesse.brandeburg@...el.com>, <intel-wired-lan@...ts.osuosl.org>,
<netdev@...r.kernel.org>, <qi.z.zhang@...el.com>, <ivecera@...hat.com>,
<sridhar.samudrala@...el.com>, <horms@...nel.org>, <edumazet@...gle.com>,
<davem@...emloft.net>, <pabeni@...hat.com>
Subject: Re: [PATCH iwl-next v8 00/15] Introduce the Parser Library
From: Jakub Kicinski <kuba@...nel.org>
Date: Thu, 24 Aug 2023 08:20:39 -0700
> On Thu, 24 Aug 2023 15:54:45 +0800 Junfeng Guo wrote:
>> Current software architecture for flow filtering offloading limited
>> the capability of Intel Ethernet 800 Series Dynamic Device
>> Personalization (DDP) Package. The flow filtering offloading in the
>> driver is enabled based on the naming parsers, each flow pattern is
>> represented by a protocol header stack. And there are multiple layers
>> (e.g., virtchnl) to maintain their own enum/macro/structure
>> to represent a protocol header (IP, TCP, UDP ...), thus the extra
>> parsers to verify if a pattern is supported by hardware or not as
>> well as the extra converters that to translate represents between
>> different layers. Every time a new protocol/field is requested to be
>> supported, the corresponding logic for the parsers and the converters
>> needs to be modified accordingly. Thus, huge & redundant efforts are
>> required to support the increasing flow filtering offloading features,
>> especially for the tunnel types flow filtering.
>
> You keep breaking the posting guidelines :(
> I already complained to people at Intel about you.
>
> The only way to push back that I can think of is to start handing out
> posting suspensions for all @intel.com addresses on netdev. Please
Ah, that collective responsibility :D
> don't make us stoop that low.
But seriously, please don't. Intel is huge and we physically can't keep
an eye on every developer or patch. I personally don't even know what
team the submitter is from. Spending 8 hrs a day on tracking every
@intel.com submission on netdev is also not something I'd like to do at
work (I mean, I'd probably like reviewing every line coming out of my
org, had I 120-150 hrs a day...).
I know that sounds cheap, but that's how I see it :z
>
>
Thanks,
Olek
Powered by blists - more mailing lists