From: Sebastian Gottschall <s.gottschall@dd-wrt.com>
To: Jakub Kicinski <kuba@kernel.org>, Felix Fietkau <nbd@nbd.name>
Cc: netdev@vger.kernel.org, Eric Dumazet <eric.dumazet@gmail.com>,
Hillf Danton <hdanton@sina.com>
Subject: Re: [PATCH v3 1/2] net: add support for threaded NAPI polling
Date: Sun, 30 Aug 2020 10:46:09 +0200 [thread overview]
Message-ID: <bb520bbe-3e6e-949f-e534-53f1425f91eb@dd-wrt.com> (raw)
In-Reply-To: <20200821184924.5b5c421c@kicinski-fedora-PC1C0HJN>
Am 22.08.2020 um 03:49 schrieb Jakub Kicinski:
> On Fri, 21 Aug 2020 21:01:50 +0200 Felix Fietkau wrote:
>> For some drivers (especially 802.11 drivers), doing a lot of work in the NAPI
>> poll function does not perform well. Since NAPI poll is bound to the CPU it
>> was scheduled from, we can easily end up with a few very busy CPUs spending
>> most of their time in softirq/ksoftirqd and some idle ones.
>>
>> Introduce threaded NAPI for such drivers based on a workqueue. The API is the
>> same except for using netif_threaded_napi_add instead of netif_napi_add.
>>
>> In my tests with mt76 on MT7621 using threaded NAPI + a thread for tx scheduling
>> improves LAN->WLAN bridging throughput by 10-50%. Throughput without threaded
>> NAPI is wildly inconsistent, depending on the CPU that runs the tx scheduling
>> thread.
>>
>> With threaded NAPI, throughput seems stable and consistent (and higher than
>> the best results I got without it).
>>
>> Based on a patch by Hillf Danton
> I've tested this patch on a non-NUMA system with a moderately
> high-network workload (roughly 1:6 network to compute cycles)
> - and it provides ~2.5% speedup in terms of RPS but 1/6/10% worse
> P50/P99/P999 latency.
>
> I started working on a counter-proposal which uses a pool of threads
> dedicated to NAPI polling. It's not unlike the workqueue code but
> trying to be a little more clever. It gives me ~6.5% more RPS but at
> the same time lowers the p99 latency by 35% without impacting other
> percentiles. (I only started testing this afternoon, so hopefully the
> numbers will improve further).
>
> I'm happy for this patch to be merged, it's quite nice, but I wanted
> to give the heads up that I may have something that would replace it...
>
> The extremely rough PoC, less than half-implemented code which is really
> too broken to share:
> https://git.kernel.org/pub/scm/linux/kernel/git/kuba/linux.git/log/?h=tapi
looks interesting. keep going
Sebastian
>
next prev parent reply other threads:[~2020-08-30 8:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-21 19:01 [PATCH v3 1/2] net: add support for threaded NAPI polling Felix Fietkau
2020-08-21 19:01 ` [PATCH v3 2/2] net: add sysfs attribute for enabling threaded NAPI Felix Fietkau
2020-08-22 1:49 ` [PATCH v3 1/2] net: add support for threaded NAPI polling Jakub Kicinski
2020-08-22 16:22 ` Eric Dumazet
2020-08-30 8:46 ` Sebastian Gottschall [this message]
2020-08-25 16:38 ` Wei Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bb520bbe-3e6e-949f-e534-53f1425f91eb@dd-wrt.com \
--to=s.gottschall@dd-wrt.com \
--cc=eric.dumazet@gmail.com \
--cc=hdanton@sina.com \
--cc=kuba@kernel.org \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox