Paolo Abeni [off-list ref] writes:

On Mon, 2019-11-25 at 12:05 +0100, Johannes Berg wrote:

quoted

On Mon, 2019-11-25 at 13:58 +0300, Alexander Lobakin wrote:

quoted

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