[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250116171102.47be0ded@kernel.org>
Date: Thu, 16 Jan 2025 17:11:02 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
Cc: Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
<pabeni@...hat.com>, Lorenzo Bianconi <lorenzo@...nel.org>, Daniel Xu
<dxu@...uu.xyz>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann
<daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, John Fastabend
<john.fastabend@...il.com>, Toke Høiland-Jørgensen
<toke@...nel.org>, Jesper Dangaard Brouer <hawk@...nel.org>, Martin KaFai
Lau <martin.lau@...ux.dev>, netdev@...r.kernel.org, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v3 1/8] net: gro: decouple GRO from the NAPI
layer
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@...nel.org>
but you need to rebase..
--
pw-bot: cr
Powered by blists - more mailing lists