[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3706ce73-6457-479c-ae4c-745ab73ec932@bp.renesas.com>
Date: Wed, 29 May 2024 20:09:06 +0100
From: Paul Barker <paul.barker.ct@...renesas.com>
To: Sergey Shtylyov <s.shtylyov@....ru>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Niklas Söderlund <niklas.soderlund+renesas@...natech.se>
Cc: Biju Das <biju.das.jz@...renesas.com>,
Claudiu Beznea <claudiu.beznea.uj@...renesas.com>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
netdev@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH v4 2/7] net: ravb: Consider busypolling status
when re-enabling interrupts
On 28/05/2024 17:47, Sergey Shtylyov wrote:
> On 5/28/24 7:44 PM, Sergey Shtylyov wrote:
>
>>> Make use of the busypolling status returned from NAPI complete to decide
>>
>> My spellchecker/translator trip over "busypolling" -- consider using
>> "busy-polling"?
>> And did you actually mean napi_complete_done()?
>
> Ah, napi_complete() also returns a result... maybe this should be reworded
> as "NAPI completion"?
>
>>> if interrupts shall be re-enabled or not. This is useful to reduce the
>>> interrupt overhead.
>>>
>>> While at it switch to using napi_complete_done() as it take into account
>>
>> Takes.
>>
>>> the work done when providing the busypolling status.
>>
>> Again, "busy-polling"?
Ack to all of the above.
I used the commit message suggested by Niklas here. I'll revise it a
little for v5...
Thanks,
--
Paul Barker
Download attachment "OpenPGP_0x27F4B3459F002257.asc" of type "application/pgp-keys" (3521 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)
Powered by blists - more mailing lists