On Wed, 15 Jan 2025 16:18:54 +0100 Alexander Lobakin wrote: > 1. struct gro_node has a 4-byte padding at the end anyway. If you > leave napi_id outside, struct napi_struct takes additional 8 bytes > (u32 napi_id + another 4-byte padding). > 2. gro_receive_skb() uses it to mark skbs. We don't want to split it > into two functions or add an `if`, as this would be less efficient, > but we need it to be NAPI-independent. The current approach doesn't > change anything for NAPI-backed GROs; for standalone ones (which > are less important currently), the embedded napi_id will be just > zero => no-op. Fine :) Acked-by: Jakub Kicinski <kuba@xxxxxxxxxx> but you need to rebase.. -- pw-bot: cr
