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

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

From: Eric Dumazet <edumazet@google.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