netdev - Re: [PATCH net-next v4 1/8] net: gro: decouple GRO from the NAPI layer

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 for Android: free password hash cracker in your pocket

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

Message-ID: <19f5473b-e7a3-4d39-a534-6ab2da2b16cf@intel.com>
Date: Fri, 7 Feb 2025 16:43:19 +0100
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Eric Dumazet <edumazet@...gle.com>
CC: Kees Cook <kees@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>, "David
 S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, "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>, Toke Høiland-Jørgensen
	<toke@...hat.com>
Subject: Re: [PATCH net-next v4 1/8] net: gro: decouple GRO from the NAPI
 layer

From: Eric Dumazet <edumazet@...gle.com>
Date: Fri, 7 Feb 2025 16:28:05 +0100

> OK, it seems there is not much to say.

I just asked for reading the details and my explanations, which I gave
several times, for your arguments and propositions for improving the
code. You know better than me that single a "I don't like this" doesn't
work here on LKML.

Since for now this is 1:1 disagreement which you don't seem to want to
resolve, anyone else can join this discussion and share his vision
(again, with arguments and propositions what wouldn't hurt hotpath).
I'm always glad to hear critics and improve code I write (I never mind
sending v5, v10 etc., which sometimes happens), but only when this would
actually give benefits to the code / perf / etc.

Putting gro_node out of napi_struct, moving napi_id back to napi_struct,
different approaches to handle fetching this ID to the skb we want to
pass to the GRO engine -- I tried all this and each of them hurts.
I don't mind sharing bloat-o-meter, pahole output etc etc, but I thought
the explanation in the commitmsg and the discussions in previous threads
explained enough.

...

Off the topic, but back in 2020 (or 2021) you were very against my idea
of using NAPI percpu caches to cache struct sk_buff there to lower MM
layer pressure when calling build_skb(). Convincing me that it doesn't
make sense, doesn't give anything etc. Now grep for 'napi_build_skb' and
look how many vendors/drivers use it. IIRC Mellanox reported +15%
switching from build_skb() some time ago.

Thanks,
Olek