[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZIGtaoFbvttiFD1r@corigine.com>
Date: Thu, 8 Jun 2023 12:28:58 +0200
From: Simon Horman <simon.horman@...igine.com>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>,
Alexander Lobakin <aleksander.lobakin@...el.com>,
intel-wired-lan@...ts.osuosl.org,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
Anirudh Venkataramanan <anirudh.venkataramanan@...el.com>,
Sudheer Mogilappagari <sudheer.mogilappagari@...el.com>,
netdev@...r.kernel.org
Subject: Re: [PATCH iwl-next v2] ice: clean up __ice_aq_get_set_rss_lut()
On Wed, Jun 07, 2023 at 09:09:57AM -0400, Przemek Kitszel wrote:
> Refactor __ice_aq_get_set_rss_lut() to improve reader experience and limit
> misuse scenarios (undesired LUT size for given LUT type).
>
> Allow only 3 RSS LUT type+size variants:
> PF LUT sized 2048, GLOBAL LUT sized 512, and VSI LUT sized 64, which were
> used on default flows prior to this commit.
>
> Prior to the change, code was mixing the meaning of @params->lut_size and
> @params->lut_type, flag assigning logic was cryptic, while long defines
> made everything harder to follow.
>
> Fix that by extracting some code out to separate helpers.
> Drop some of "shift by 0" statements that originated from Intel's
> internal HW documentation.
>
> Drop some redundant VSI masks (since ice_is_vsi_valid() gives "valid" for
> up to 0x300 VSIs).
>
> After sweeping all the defines out of struct ice_aqc_get_set_rss_lut,
> it fits into 7 lines.
>
> Finally apply some cleanup to the callsite
> (use of the new enums, tmp var for lengthy bit extraction).
>
> Note that flags for 128 and 64 sized VSI LUT are the same,
> and 64 is used everywhere in the code (updated to new enum here), it just
> happened that there was 128 in flag name.
>
> __ice_aq_get_set_rss_key() uses the same VSI valid bit, make constant
> common for it and __ice_aq_get_set_rss_lut().
>
> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Reviewed-by: Simon Horman <simon.horman@...igine.com>
Powered by blists - more mailing lists