On Mon, 27 Feb 2017 12:18:31 -0800 Eric Dumazet <eric.duma...@gmail.com> wrote:
> This can happen with busy polling users, or if gro_flush_timeout is > used. But some other uses of napi_schedule() in drivers can cause this > as well. Where were IRQ's re-enabled? > thread 1 thread 2 (could be on same cpu) > > // busy polling or napi_watchdog() > napi_schedule(); > ... > napi->poll() > > device polling: > read 2 packets from ring buffer > Additional 3rd packet is available. > device hard irq > > // does nothing because > NAPI_STATE_SCHED bit is owned by thread 1 > napi_schedule(); > > napi_complete_done(napi, 2); > rearm_irq(); Maybe just as simple as using irqsave/irqrestore in driver.
