netdev - Re: [PATCH iwl-next v9 00/15] Introduce the Parser Library

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] [day] [month] [year] [list]

Message-ID: <f770f4b3-f4f1-4ef7-e80a-d7c75c8b18e0@intel.com>
Date: Tue, 12 Sep 2023 15:37:27 -0500
From: "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To: Tom Herbert <tom@...bertland.com>
CC: Jakub Kicinski <kuba@...nel.org>, 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/9/2023 12:34 PM, Tom Herbert wrote:
> On Thu, Sep 7, 2023 at 12:10 PM Samudrala, Sridhar
> <sridhar.samudrala@...el.com> wrote:
>>
>>
>>
>> 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.
> 
> Sridhar,
> 
> Okay, the DDP includes a programmable parser to some extent, and these
> patches support the driver logic to support that programmable hardware
> parser in ICE. It's still unclear to me how the rest of the world will
> use this. When you say you the information "is used to figure out all
> the metadata required to add a filter rule", who is adding these
> filter rules and what APIs are they using? 

The filter rules are added by non-linux VF drivers that provide a 
user-api to pass raw packet along with a mask to indicate the packet 
header fields to be matched. The VF driver passes this rule to the PF 
driver via VF<->PF mailbox using virtchnl API.

> Considering you mention
> it's not applicable to kernel flow dissector that leads me to believe
> that you're viewing hardware parser capabilities to be independent of
> the kernel and might even be using vendor proprietary tools to program
> the parser. But as I said, hardware parsers are becoming common, users
> benefit if we can provide common and consistent tools to program and
> use them.

Sure. But at this time this patch series is not enabling parser offload 
or configuration of parser. Only makes the rule programming to be more 
flexible.