linux-kernel - Re: [PATCH net-next v4 0/8] bpf: cpumap: enable GRO for XDP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0a8aac38-a221-4046-8c8a-a019602e25dc@intel.com>
Date: Wed, 12 Feb 2025 15:22:55 +0100
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: Eric Dumazet <edumazet@...gle.com>, Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>, 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 v4 0/8] bpf: cpumap: enable GRO for XDP_PASS
 frames

From: Jakub Kicinski <kuba@...nel.org>
Date: Mon, 10 Feb 2025 16:35:29 -0800

> On Mon, 10 Feb 2025 16:31:52 +0100 Alexander Lobakin wrote:
>> This was rejected by Kuba in v2.
>> He didn't like to have napi_id two times within napi_struct (one inside
>> gro_node, one outside).
> 
> Do you mean:
> 
>   the napi_id in gro sticks out..
> 
> https://lore.kernel.org/netdev/20250113130104.5c2c02e0@kernel.org/ ?
> 
> That's more of a nudge to try harder than a "no". We explored 
> the alternatives, there's no perfect way to layer this. I think 
> Eric's suggestion is probably as clean as we can get.

You mean to cache napi_id in gro_node?

Then we get +8 bytes to sizeof(napi_struct) for little reason... Dunno,
if you really prefer, I can do it that way.

OTOH you gave Acked-by on struct_group(), then Eric appeared and you
took your ack back :D

Thanks,
Olek