netdev - Re: [Intel-wired-lan] [PATCH iwl-next v5 09/12] iavf: refactor iavf_clean_rx_irq to support legacy and flex descriptors

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: <3029ae3c-1c05-405f-a436-46b27498c6b1@intel.com>
Date: Fri, 26 Apr 2024 09:15:37 +0200
From: Mateusz Polchlopek <mateusz.polchlopek@...el.com>
To: Sunil Kovvuri Goutham <sgoutham@...vell.com>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "horms@...nel.org"
	<horms@...nel.org>, "anthony.l.nguyen@...el.com"
	<anthony.l.nguyen@...el.com>, Jacob Keller <jacob.e.keller@...el.com>,
	Wojciech Drewek <wojciech.drewek@...el.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v5 09/12] iavf: refactor
 iavf_clean_rx_irq to support legacy and flex descriptors



On 4/23/2024 12:51 PM, Sunil Kovvuri Goutham wrote:
> 
> 
>> -----Original Message-----
>> From: Mateusz Polchlopek <mateusz.polchlopek@...el.com>
>> Sent: Thursday, April 18, 2024 10:55 AM
>> To: intel-wired-lan@...ts.osuosl.org
>> Cc: netdev@...r.kernel.org; horms@...nel.org; anthony.l.nguyen@...el.com;
>> Jacob Keller <jacob.e.keller@...el.com>; Wojciech Drewek
>> <wojciech.drewek@...el.com>; Mateusz Polchlopek
>> <mateusz.polchlopek@...el.com>
>> Subject: [EXTERNAL] [Intel-wired-lan] [PATCH iwl-next v5 09/12] iavf: refactor
>> iavf_clean_rx_irq to support legacy and flex descriptors
>>
>> From: Jacob Keller <jacob.e.keller@...el.com>
>>
>> Using VIRTCHNL_VF_OFFLOAD_FLEX_DESC, the iAVF driver is capable of
>> negotiating to enable the advanced flexible descriptor layout. Add the flexible
>> NIC layout (RXDID=2) as a member of the Rx descriptor union.
>>
>> Also add bit position definitions for the status and error indications that are
>> needed.
>>
>> The iavf_clean_rx_irq function needs to extract a few fields from the Rx
>> descriptor, including the size, rx_ptype, and vlan_tag.
>> Move the extraction to a separate function that decodes the fields into a
>> structure. This will reduce the burden for handling multiple descriptor types by
>> keeping the relevant extraction logic in one place.
>>
>> To support handling an additional descriptor format with minimal code
>> duplication, refactor Rx checksum handling so that the general logic is
>> separated from the bit calculations. Introduce an iavf_rx_desc_decoded
>> structure which holds the relevant bits decoded from the Rx descriptor.
>> This will enable implementing flexible descriptor handling without duplicating
>> the general logic twice.
>>
>> Introduce an iavf_extract_flex_rx_fields, iavf_flex_rx_hash, and
>> iavf_flex_rx_csum functions which operate on the flexible NIC descriptor
>> format instead of the legacy 32 byte format. Based on the negotiated RXDID,
>> select the correct function for processing the Rx descriptors.
>>
>> With this change, the Rx hot path should be functional when using either the
>> default legacy 32byte format or when we switch to the flexible NIC layout.
>>
>> Modify the Rx hot path to add support for the flexible descriptor format and
>> add request enabling Rx timestamps for all queues.
>>
>> As in ice, make sure we bump the checksum level if the hardware detected a
>> packet type which could have an outer checksum. This is important because
>> hardware only verifies the inner checksum.
>>
> 
> What is the relevance of these csum related changes wrt introducing flex descriptor parsing
> for HW timestamps ?
> 
> Thanks,
> Sunil.

Because of different types of descriptors we need to calculate csums in
slightly different way (based on the descriptor type). That's why we
have separated functions for both cases and enclosed common part in
another.

Did I answer Your question?

Thanks
Mateusz