[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0101016ea2790643-5f91d22f-e322-497e-8c58-34f5942bd2af-000000@us-west-2.amazonses.com>
Date: Mon, 25 Nov 2019 12:11:10 +0000
From: Kalle Valo <kvalo@...eaurora.org>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Johannes Berg <johannes@...solutions.net>,
Alexander Lobakin <alobakin@...nk.ru>,
Edward Cree <ecree@...arflare.com>,
Nicholas Johnson <nicholas.johnson-opensource@...look.com.au>,
David Miller <davem@...emloft.net>, jiri@...lanox.com,
edumazet@...gle.com, idosch@...lanox.com, petrm@...lanox.com,
sd@...asysnail.net, f.fainelli@...il.com,
jaswinder.singh@...aro.org, ilias.apalodimas@...aro.org,
linux-kernel@...r.kernel.org, emmanuel.grumbach@...el.com,
luciano.coelho@...el.com, linuxwifi@...el.com,
netdev@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: [PATCH v2 net-next] net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()
Paolo Abeni <pabeni@...hat.com> 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
Powered by blists - more mailing lists