Re: [Intel-wired-lan] [PATCH iwl-next v3 2/9] ice: use cacheline groups for ice_rx_ring structure

[Jacob Keller <jacob.e.keller@intel.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2019 bytes --]



On 11/14/2025 7:36 AM, Alexander Lobakin wrote:
> From: Jacob Keller <jacob.e.keller@intel.com>
> Date: Fri, 7 Nov 2025 15:31:46 -0800
> 
>> The ice ring structure was reorganized back by commit 65124bbf980c ("ice:
>> Reorganize tx_buf and ring structs"), and later split into a separate
>> ice_rx_ring structure by commit e72bba21355d ("ice: split ice_ring onto
>> Tx/Rx separate structs")
>>
>> The ice_rx_ring structure has comments left over from this prior
>> reorganization indicating which fields belong to which cachelines.
>> Unfortunately, these comments are not all accurate. The intended layout is
>> for x86_64 systems with a 64-byte cache.
>>
>>  * Cacheline 1 spans from the start of the struct to the end of the rx_fqes
>>    and xdp_buf union. The comments correctly match this.
>>
>>  * Cacheline 2 spans from hdr_fqes to the end of hdr_truesize, but the
>>    comment indicates it should end xdp and xsk union.
>>
>>  * Cacheline 3 spans from the truesize field to the xsk_pool, but the
>>    comment wants this to be from the pkt_ctx down to the rcu head field.
>>
>>  * Cacheline 4 spans from the rx_hdr_len down to the flags field, but the
>>    comment indicates that it starts back at the ice_channel structure
>>    pointer.
>>
>>  * Cacheline 5 is indicated to cover the xdp_rxq. Because this field is
>>    aligned to 64 bytes, this is actually true. However, there is a large 45
>>    byte gap at the end of cacheline 4.
> 
> Sorry for reviewing this so late, but these comments really are outdated
> as hell and don't really reflect what we'd like to achieve.
> 
> I would like to work together with you on rearranging and packing both
> structures in an optimal way, the same what I did quite a bit ago for idpf.
> 
> Maybe we could drop the series from the next-queue for now?
> 

Sounds good. I can probably also respin the other parts to avoid needing
to rely on this change, and we can work together to fix this properly.

Thanks,
Jake

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]