[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8df3c9c6-19ed-acc8-f2ac-1826a81ab53c@intel.com>
Date: Thu, 7 Sep 2023 14:10:14 -0500
From: "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To: Tom Herbert <tom@...bertland.com>, Jakub Kicinski <kuba@...nel.org>
CC: Junfeng Guo <junfeng.guo@...el.com>, <intel-wired-lan@...ts.osuosl.org>,
<netdev@...r.kernel.org>, <anthony.l.nguyen@...el.com>,
<jesse.brandeburg@...el.com>, <qi.z.zhang@...el.com>, <ivecera@...hat.com>,
<horms@...nel.org>, <edumazet@...gle.com>, <davem@...emloft.net>,
<pabeni@...hat.com>
Subject: Re: [PATCH iwl-next v9 00/15] Introduce the Parser Library
On 9/5/2023 6:05 PM, Tom Herbert wrote:
<snip>
> Yes, creating an elaborate mechanism that is only usable for one
> vendor, e.g. a feature of DDP, really isn't very helpful. Parsing is a
> very common operation in the networking stack, and if there's
> something with the vanglorious name of "Parser Library" really should
> start off as being a common, foundational, vendor agnostic library to
> solve the larger problem and provide the most utility. The common
> components would define consistent user and kernel interfaces for
> parser offload, interfaces into the NIC drivers would be defined to
> allow different vendors to implement parser offload in their devices.
I think naming this framework as 'parser library' may have caused the
misunderstanding. Will fix in the next revision. This is not a generic
network packet parser and not applicable to kernel flow dissector. It is
specific to ice and enables the driver to learn the hardware parser
capabilities from the DDP package that is downloaded to hardware. This
information along with the raw packet/mask is used to figure out all the
metadata required to add a filter rule.
Powered by blists - more mailing lists