Re: [PATCH net v2 0/4] r8152: fix scheduling napi

[David Miller]

From: Hayes Wang <hayeswang@xxxxxxxxxxx>
Date: Wed, 25 Jan 2017 16:13:17 +0800

> v2:
> Add smp_mb__after_atomic() for patch #1.
> 
> v1:
> Scheduling the napi during the following periods would let it be ignored.
> And the events wouldn't be handled until next napi_schedule() is called.
> 
> 1. after napi_disable and before napi_enable().
> 2. after all actions of napi function is completed and before calling
>    napi_complete().
> 
> If no next napi_schedule() is called, tx or rx would stop working.
> 
> In order to avoid these situations, the followings solutions are applied.
> 
> 1. prevent start_xmit() from calling napi_schedule() during runtime suspend
>    or after napi_disable().
> 2. re-schedule the napi for tx if it is necessary.
> 3. check if any rx is finished or not after napi_enable().

I think the fundamental issue is that since you can't stop URBs from
queueing up, you cannot properly synchronize NAPI and schedule polling
properly.

>From my perspective what happened here is you want GRO support, but it
comes at the expense of this extremely racey NAPI support which does
not at all achieve one of the main advantages of NAPI which is
interrupt mitigation.

It would have been so much better to implement a generic way for
drivers to get GRO support without NAPI, especially if their packet
feeding engine works the way that the USB networking drivers's do.