netdev - Re: [PATCH] net: add support for threaded NAPI polling

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]

Message-ID: <0de774d0-7e9e-8a44-0f0c-584a9cb9ee96@dd-wrt.com>
Date:   Thu, 30 Jul 2020 19:19:17 +0200
From:   Sebastian Gottschall <s.gottschall@...wrt.com>
To:     David Laight <David.Laight@...LAB.COM>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Felix Fietkau <nbd@....name>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     Hillf Danton <hdanton@...a.com>
Subject: Re: [PATCH] net: add support for threaded NAPI polling


Am 30.07.2020 um 17:42 schrieb David Laight:
> From: Sebastian Gottschall
>> Sent: 30 July 2020 15:30
> ...
>>> Quite frankly, I do believe this STATE_THREADED status should be a generic NAPI attribute
>>> that can be changed dynamically, at admin request, instead of having to change/recompile
>>> a driver.
>> thats not that easy. wifi devices do use dummy netdev devices. they are
>> not visible to sysfs and other administrative options.
>> so changing it would just be possible if a special mac80211 based
>> control would be implemented for these drivers.
>> for standard netdev devices it isnt a big thing to implement a
>> administrative control by sysfs (if you are talking about such a feature)
> ISTM that a global flag that made all NAPI callbacks be made
> from a worker thread rather than softint would be more approriate.
> Or even something that made the softint callbacks themselves
> only run an a specific high(ish) priority kernel thread.
>
> While it might slow down setups that need very low ethernet
> latency it will help those that don't want application RT threads
> to be 'stolen' by the softint code while they hold application
> mutex or are waiting to be woken by a cv.
this will not work either. i already identified drivers which are 
incompatible with that approach. (marvell mvneta for instance)
so threading should be a feature which should be enabled or disabled on 
known working chipsets. but it cannot be used as
set and forget feature for everything unless the specific driver are fixed.
>
> 	David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)