linux-kernel - Re: [PATCH net-next v2] net/core: add optional threading for backlog processing

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] [day] [month] [year] [list]

Date:   Thu, 30 Mar 2023 13:11:32 +0200
From:   Felix Fietkau <nbd@....name>
To:     Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, Jonathan Corbet <corbet@....net>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2] net/core: add optional threading for backlog
 processing

On 30.03.23 13:01, Paolo Abeni wrote:
> On Tue, 2023-03-28 at 16:16 -0700, Jakub Kicinski wrote:
>> On Tue, 28 Mar 2023 21:59:25 +0200 Felix Fietkau wrote:
>> > When dealing with few flows or an imbalance on CPU utilization, static RPS
>> > CPU assignment can be too inflexible. Add support for enabling threaded NAPI
>> > for backlog processing in order to allow the scheduler to better balance
>> > processing. This helps better spread the load across idle CPUs.
>> 
>> Can you share some numbers vs a system where RPS only spreads to 
>> the cores which are not running NAPI?
>> 
>> IMHO you're putting a lot of faith in the scheduler and you need 
>> to show that it actually does what you say it will do.
I will run some more tests as soon as I have time for it.

> I have the same feeling. From your description I think some gain is
> possible if there are no other processes running except
> ksoftirq/rps/threaded napi.
> 
> I guess that the above is expect average state for a small s/w router,
> but if/when routing daemon/igmp proxy/local web server kicks-in you
> should notice a measurable higher latency (compared to plain RPS in the
> same scenario)???
Depends on the process priority, I guess.

The main thing I'm trying to fix is the fact that RPS as implemented 
right now is too static for devices routing traffic at CPU capacity limit.
Even if you manage to tune properly for simple ethernet NAT, then adding 
WLAN to the mix can easily throw a wrench into the picture as well, 
because its hard to cover different shifting usage patterns with a 
simple static assignment.

- Felix