linux-kernel - RE: [RFC 0/7] Add support to process rx packets in thread

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: <cb54c2746a3d4ce695e3bda8b576b40e@AcuMS.aculab.com>
Date:   Sun, 26 Jul 2020 11:16:00 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Sebastian Gottschall' <s.gottschall@...wrt.com>,
        Hillf Danton <hdanton@...a.com>
CC:     Andrew Lunn <andrew@...n.ch>,
        Rakesh Pillai <pillair@...eaurora.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "ath10k@...ts.infradead.org" <ath10k@...ts.infradead.org>,
        "dianders@...omium.org" <dianders@...omium.org>,
        Markus Elfring <Markus.Elfring@....de>,
        "evgreen@...omium.org" <evgreen@...omium.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "johannes@...solutions.net" <johannes@...solutions.net>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kvalo@...eaurora.org" <kvalo@...eaurora.org>
Subject: RE: [RFC 0/7] Add support to process rx packets in thread

From: Sebastian Gottschall <s.gottschall@...wrt.com>
> Sent: 25 July 2020 16:42
> >> i agree. i just can say that i tested this patch recently due this
> >> discussion here. and it can be changed by sysfs. but it doesnt work for
> >> wifi drivers which are mainly using dummy netdev devices. for this i
> >> made a small patch to get them working using napi_set_threaded manually
> >> hardcoded in the drivers. (see patch bellow)

> > By CONFIG_THREADED_NAPI, there is no need to consider what you did here
> > in the napi core because device drivers know better and are responsible
> > for it before calling napi_schedule(n).

> yeah. but that approach will not work for some cases. some stupid
> drivers are using locking context in the napi poll function.
> in that case the performance will runto shit. i discovered this with the
> mvneta eth driver (marvell) and mt76 tx polling (rx  works)
> for mvneta is will cause very high latencies and packet drops. for mt76
> it causes packet stop. doesnt work simply (on all cases no crashes)
> so the threading will only work for drivers which are compatible with
> that approach. it cannot be used as drop in replacement from my point of
> view.
> its all a question of the driver design

Why should it make (much) difference whether the napi callbacks (etc)
are done in the context of the interrupted process or that of a
specific kernel thread.
The process flags (or whatever) can even be set so that it appears
to be the expected 'softint' context.

In any case running NAPI from a thread will just show up the next
piece of code that runs for ages in softint context.
I think I've seen the tail end of memory being freed under rcu
finally happening under softint and taking absolutely ages.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)