netdev - Re: [PATCH net-next 0/2] net: default_rps

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: <df8772b86a072b21500392aa45b72ac86d6983e4.camel@redhat.com>
Date:   Wed, 15 Feb 2023 21:33:01 +0100
From:   Paolo Abeni <pabeni@...hat.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Shuah Khan <shuah@...nel.org>
Subject: Re: [PATCH net-next 0/2] net: default_rps_mask follow-up

On Wed, 2023-02-15 at 11:29 -0800, Jakub Kicinski wrote:
> On Wed, 15 Feb 2023 19:33:35 +0100 Paolo Abeni wrote:
> > The first patch namespacify the setting: once proper isolation
> > is in place in the main namespace, additional demux in the child
> > namespaces will be redundant.
> 
> Would you mind spelling this out again for me? If I create a veth with
> the peer in a netns, the local end will get one RPS mask and the netns
> end will get a RPS mask from the netns. 

Which should be likely no RPS mask at all.

> If the daemon is not aware of having to configure RPS masks 
> (which I believe was your use case) then
> it won't set the default mask in the netns either.. 

The goal is exactly that: avoiding the long way via the daemon (or
other user-space tool) and the sysfs.

Without this patch the child-ns veth gets the same RPS setting as the
main veth one.

That is not needed, as every other devices forwarding packets to the
netns has proper isolation (RPS or IRQ affinity) already set. If the
child ns device RPS configuration is left unchanged, the incoming
packets in the child netns go through an unneeded RPS stage, which
could be a bad thing if the selected CPU is on a different NUMA node.

Please let me know if the above clarifies the scenario.

Cheers,

Paolo