From: Hayes Wang
Date: Thu, 26 Jan 2017 03:04:45 +
> May you apply these patches first, until I find another way to replace
> current one?
Yes, I will.
David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, January 26, 2017 3:31 AM
[...]
> 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
From: Hayes Wang
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.
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