netdev - RE: [Intel-wired-lan] [PATCH iwl-next v2 2/2] net: intel: move RSS packet classifier types to libie

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: <SJ0PR11MB5865D93024C9B7356813EF838F99A@SJ0PR11MB5865.namprd11.prod.outlook.com>
Date: Thu, 22 May 2025 18:17:16 +0000
From: "Romanowski, Rafal" <rafal.romanowski@...el.com>
To: "Keller, Jacob E" <jacob.e.keller@...el.com>, Intel Wired LAN
	<intel-wired-lan@...ts.osuosl.org>, "Nguyen, Anthony L"
	<anthony.l.nguyen@...el.com>, netdev <netdev@...r.kernel.org>
CC: "Keller, Jacob E" <jacob.e.keller@...el.com>, "Kitszel, Przemyslaw"
	<przemyslaw.kitszel@...el.com>, Simon Horman <horms@...nel.org>, "Loktionov,
 Aleksandr" <aleksandr.loktionov@...el.com>
Subject: RE: [Intel-wired-lan] [PATCH iwl-next v2 2/2] net: intel: move RSS
 packet classifier types to libie

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of Jacob
> Keller
> Sent: Monday, May 5, 2025 10:14 PM
> To: Intel Wired LAN <intel-wired-lan@...ts.osuosl.org>; Nguyen, Anthony L
> <anthony.l.nguyen@...el.com>; netdev <netdev@...r.kernel.org>
> Cc: Keller, Jacob E <jacob.e.keller@...el.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@...el.com>; Simon Horman <horms@...nel.org>; Loktionov,
> Aleksandr <aleksandr.loktionov@...el.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v2 2/2] net: intel: move RSS packet
> classifier types to libie
> 
> The Intel i40e, iavf, and ice drivers all include a definition of the packet classifier
> filter types used to program RSS hash enable bits. For i40e, these bits are used for
> both the PF and VF to configure the PFQF_HENA and VFQF_HENA registers.
> 
> For ice and iAVF, these bits are used to communicate the desired hash enable
> filter over virtchnl via its struct virtchnl_rss_hashena. The virtchnl.h header
> makes no mention of where the bit definitions reside.
> 
> Maintaining a separate copy of these bits across three drivers is cumbersome.
> Move the definition to libie as a new pctype.h header file.
> Each driver can include this, and drop its own definition.
> 
> The ice implementation also defined a ICE_AVF_FLOW_FIELD_INVALID, intending
> to use this to indicate when there were no hash enable bits set. This is confusing,
> since the enumeration is using bit positions. A value of 0
> *should* indicate the first bit. Instead, rewrite the code that uses
> ICE_AVF_FLOW_FIELD_INVALID to just check if the avf_hash is zero. From
> context this should be clear that we're checking if none of the bits are set.
> 
> The values are kept as bit positions instead of encoding the BIT_ULL directly into
> their value. While most users will simply use BIT_ULL immediately, i40e uses the
> macros both with BIT_ULL and test_bit/set_bit calls.
> 
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
> Reviewed-by: Simon Horman <horms@...nel.org>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@...el.com>
> Signed-off-by: Jacob Keller <jacob.e.keller@...el.com>
> ---

Tested-by: Rafal Romanowski <rafal.romanowski@...el.com>