netdev - Re: [PATCH v2 net-next] net: core: use listified Rx for GRO_NORMAL in napi_gro

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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