Re: [PATCH net-next v3] net: napi: Skip last poll when arming gro timer in busy poll

[Paolo Abeni <pabeni@redhat.com>]

On 5/21/26 5:42 PM, Martin Karsten wrote:
> On 2026-05-21 10:13, Paolo Abeni wrote:
>> On 5/18/26 8:13 PM, Martin Karsten wrote:
>>> +	} else {
>>> +		/* All we really want here is to re-enable device interrupts. */
>>> +		rc = napi->poll(napi, budget);
>>> +		/* We can't gro_normal_list() here, because napi->poll() might
>>> +		 * have rearmed the napi (napi_complete_done()) in which case
>>> +		 * it could already be running on another CPU.
>>> +		 */
>>> +		trace_napi_poll(napi, rc, budget);
>>> +		netpoll_poll_unlock(have_poll_lock);
>>> +		if (rc == budget) {
>>> +			gro_normal_list(&napi->gro);
>>
>> Not blocking, but I find the above slightly confusing after this
>> refactor. Perhaps it should be re-worded?
> 
> I'd be happy to reword, but I am not familiar with the internals of gro 
> processing, so would appreciate any help I can get?
> 
> Should I try-and-error via subsequent patch submission(s) or can you 
> comment on this version:
> 
> 		/* Use the driver poll to re-enable device interrupts. */
> 		rc = napi->poll(napi, budget);
> 		trace_napi_poll(napi, rc, budget);
> 		netpoll_poll_unlock(have_poll_lock);
> 		if (rc == budget) {
> 			/* If napi_complete_done has not been called by the
> 			 * driver poll, the napi needs to be rescheduled.
> 			 * Use the opportunity to pass up completed gro skbs.

Possibly something alike the following:

			/* More work to do: no concurrent napi-related 	
			 * irq is possible and the current thread can
			 * pass up the pending skb batch.
			 */

?