[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <473dee27-1012-b9da-2353-bb1c814f38ba@huawei.com>
Date: Mon, 10 Apr 2023 17:20:52 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Jesper Dangaard Brouer <jbrouer@...hat.com>,
Jakub Kicinski <kuba@...nel.org>
CC: <brouer@...hat.com>, <davem@...emloft.net>,
<netdev@...r.kernel.org>, <edumazet@...gle.com>,
<pabeni@...hat.com>, <hawk@...nel.org>,
<ilias.apalodimas@...aro.org>
Subject: Re: [RFC net-next v2 1/3] net: skb: plumb napi state thru skb freeing
paths
On 2023/4/10 1:28, Jesper Dangaard Brouer wrote:
>
>
> On 07/04/2023 17.28, Jakub Kicinski wrote:
>> On Fri, 7 Apr 2023 07:14:02 -0700 Jakub Kicinski wrote:
>>>>> -static bool skb_pp_recycle(struct sk_buff *skb, void *data)
>>>>> +static bool skb_pp_recycle(struct sk_buff *skb, void *data, bool in_normal_napi)
>>>>
>>>> What does *normal* means in 'in_normal_napi'?
>>>> can we just use in_napi?
>>>
>>> Technically netpoll also calls NAPI, that's why I threw in the
>>> "normal". If folks prefer in_napi or some other name I'm more
>>> than happy to change. Naming is hard.
>>
>> Maybe I should rename it to in_softirq ? Or napi_safe ?
>> Because __kfree_skb_defer() gets called from the Tx side.
>> And even the Rx deferred free isn't really *in* NAPI.
>>
>
> I like the name "napi_safe".
+1.
>
> --Jesper
>
> .
>
Powered by blists - more mailing lists