Subject: Re: [PATCH net-next 1/3] net: skb: plumb napi state thru skb freeing paths

From: Jakub Kicinski <[email-masked]>
Date: Wed, 12 Apr 2023 21:20:59 -0700

On Wed, 12 Apr 2023 11:29:08 +0200 Jesper Dangaard Brouer wrote:
> On 11/04/2023 22.17, Jakub Kicinski wrote:
> > We maintain a NAPI-local cache of skbs which is fed by napi_consume_skb().
> > Going forward we will also try to cache head and data pages.
> > Plumb the "are we in a normal NAPI context" information thru
> > deeper into the freeing path, up to skb_release_data() and
> > skb_free_head()/skb_pp_recycle().
> > 
> > Use "bool in_normal_napi" rather than bare "int budget",  
> 
> The code was changed to "napi_safe", the desc should reflect this ;-)

Ah, sed would have been a better idea after all :)

> > the further we get from NAPI the more confusing the budget
> > argument may seem (particularly whether 0 or MAX is the
> > correct value to pass in when not in NAPI).  
> 
> I do like the code cleanup.
> It is worth explaining/mentioning that where budget==0 comes from?
> 
> (Cc. Alex, please correct me.)
> My understanding is that this is caused by netconsole/netpoll (see
> net/core/netpoll.c func poll_one_napi()), which is a kernel (net)console
> debugging facility sending UDP packets via using only TX side of
> napi_poll.  Thus, we are really trying to protect against doing these
> recycle tricks for when netpoll/netconcole is running (which I guess
> makes sense as we are likely printing/sending an OOPS msg over UDP).

Yup, that's correct. I'll add a sentence or two to that effect.