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