Re: [PATCH net-next v4 0/8] bpf: cpumap: enable GRO for XDP_PASS frames

[Alexander Lobakin <aleksander.lobakin@intel.com>]

From: Jakub Kicinski <kuba@kernel.org>
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