Re: [PATCH net-next] net: remove gfp_mask from napi_alloc_skb()

From
Alexander Lobakin <aleksander.lobakin@intel.com>
Date
2024-03-26 09:56:57
Also in
intel-wired-lan
Reply to
Jakub Kicinski, 2024-03-25
From: Jakub Kicinski <kuba@kernel.org>
Date: Mon, 25 Mar 2024 15:41:14 -0700
__napi_alloc_skb() is napi_alloc_skb() with the added flexibility
of choosing gfp_mask. This is a NAPI function, so GFP_ATOMIC is
implied. The only practical choice the caller has is whether to
set __GFP_NOWARN. But that's a false choice, too, allocation failures
in atomic context will happen, and printing warnings in logs,
effectively for a packet drop, is both too much and very likely
non-actionable.

This leads me to a conclusion that most uses of napi_alloc_skb()
are simply misguided, and should use __GFP_NOWARN in the first
place. We also have a "standard" way of reporting allocation
failures via the queue stat API (qstats::rx-alloc-fail).

The direct motivation for this patch is that one of the drivers
used at Meta calls napi_alloc_skb() (so prior to this patch without
__GFP_NOWARN), and the resulting OOM warning is the top networking
warning in our fleet.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Nice cleanup!

Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
---
This is changing mostly the Intel drivers, if the choice of
flags is important there, please do let me know, why IDPF
uses bare GFP_ATOMIC, specifically.
idpf uses bare atomic w/o nowarn because the author didn't pay attention
to it. The change is totally safe.

Thanks,
Olek
Thread (2 messages) 2 messages, 2 authors, last reply 2024-03-26
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help