[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aSWCT0eB79P6h18F@horms.kernel.org>
Date: Tue, 25 Nov 2025 10:17:51 +0000
From: Simon Horman <horms@...nel.org>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: Aleksandr Loktionov <aleksandr.loktionov@...el.com>,
Alexander Lobakin <aleksander.lobakin@...el.com>,
Tony Nguyen <anthony.l.nguyen@...el.com>,
Przemek Kitszel <przemyslaw.kitszel@...el.com>,
intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org
Subject: Re: [PATCH iwl-next v4 6/6] ice: convert all ring stats to
u64_stats_t
On Thu, Nov 20, 2025 at 12:20:46PM -0800, Jacob Keller wrote:
> After several cleanups, the ice driver is now finally ready to convert all
> Tx and Rx ring stats to the u64_stats_t and proper use of the u64 stats
> APIs.
>
> The final remaining part to cleanup is the VSI stats accumulation logic in
> ice_update_vsi_ring_stats().
>
> Refactor the function and its helpers so that all stat values (and not
> just pkts and bytes) use the u64_stats APIs. The
> ice_fetch_u64_(tx|rx)_stats functions read the stat values using
> u64_stats_read and then copy them into local ice_vsi_(tx|rx)_stats
> structures. This does require making a new struct with the stat fields as
> u64.
>
> The ice_update_vsi_(tx|rx)_ring_stats functions call the fetch functions
> per ring and accumulate the result into one copy of the struct. This
> accumulated total is then used to update the relevant VSI fields.
>
> Since these are relatively small, the contents are all stored on the stack
> rather than allocating and freeing memory.
>
> Once the accumulator side is updated, the helper ice_stats_read and
> ice_stats_inc and other related helper functions all easily translate to
> use of u64_stats_read and u64_stats_inc. This completes the refactor and
> ensures that all stats accesses now make proper use of the API.
>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@...el.com>
> Signed-off-by: Jacob Keller <jacob.e.keller@...el.com>
Thanks.
I do notice in the cover that you solicit alternate approaches to
lead to a yet cleaner solution. But I think that the approach you have
taken does significantly improve both the cleanliness and correctness
of the code. So even if we think of something better later, I think
this is a good step to take now.
Thanks for breaking out the series into bite-sized chunks, especially
the last few patches. It really helped me in my review.
Reviewed-by: Simon Horman <horms@...nel.org>
Powered by blists - more mailing lists