From: Jakub Kicinski <kuba@xxxxxxxxxx>
Date: Wed, 12 Feb 2025 10:29:36 -0800
> On Wed, 12 Feb 2025 16:55:52 +0100 Alexander Lobakin wrote:
>>> You mean to cache napi_id in gro_node?
>>>
>>> Then we get +8 bytes to sizeof(napi_struct) for little reason...
>
> Right but I think the expectation would be that we don't ever touch
> that on the fast path, right? The "real" napi_id would basically
> go down below:
>
> /* control-path-only fields follow */
>
> 8B of cold data doesn't matter at all. But I haven't checked if
> we need the napi->napi_id access anywhere hot, do we?
Hmm, if the "hot" napi_id will be in cached in gro_node, then maybe
napi_struct::napi_id could really be in the cold part, let me recheck.
>
>>> Dunno, if you really prefer, I can do it that way.
>>
>> Alternative to avoid +8 bytes:
>>
>> struct napi_struct {
>> ...
>>
>> union {
>> struct gro_node gro;
>> struct {
>> u8 pad[offsetof(struct gro_node, napi_id)];
>> u32 napi_id;
>> };
>> };
>>
>> This is effectively the same what struct_group() does, just more ugly.
>> But allows to declare gro_node separately.
Thanks,
Olek
