Paolo Abeni <pabeni@xxxxxxxxxx> writes: > On Mon, 2019-11-25 at 12:05 +0100, Johannes Berg wrote: >> On Mon, 2019-11-25 at 13:58 +0300, Alexander Lobakin wrote: >> >> > Agree. I mean, we _can_ handle this particular problem from networking >> > core side, but from my point of view only rethinking driver's logic is >> > the correct way to solve this and other issues that may potentionally >> > appear in future. >> >> Do tell what you think it should be doing :) >> >> One additional wrinkle is that we have firmware notifications, command >> completions and actual RX interleaved, so I think we do want to have >> interrupts for the notifications and command completions? > > I think it would be nice moving the iwlwifi driver to full/plain NAPI > mode. The interrupt handler could keep processing extra work as it does > now and queue real pkts on some internal queue, and than schedule the > relevant napi, which in turn could process such queue in the napi poll > method. Likely I missed tons of details and/or oversimplified it... Sorry for hijacking the thread, but I have a patch pending for ath10k (another wireless driver) which adds NAPI support to SDIO devices: https://patchwork.kernel.org/patch/11188393/ I think it does just what you suggested, but I'm no NAPI expert and would appreciate if someone more knowledgeable could take a look :) -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
