[net-next,0/2] net: default_rps_mask follow-up

Message

Paolo Abeni Feb. 15, 2023, 6:33 p.m. UTC

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.
The 2nd patch adds more self-tests coverage.

Paolo Abeni (2):
  net: make default_rps_mask a per netns attribute
  self-tests: more rps self tests

 include/linux/netdevice.h                     |  1 -
 include/net/netns/core.h                      |  5 ++
 net/core/net-sysfs.c                          | 23 ++++++---
 net/core/sysctl_net_core.c                    | 50 ++++++++++++++-----
 .../testing/selftests/net/rps_default_mask.sh | 41 ++++++++++-----
 5 files changed, 87 insertions(+), 33 deletions(-)

Comments

Jakub Kicinski Feb. 15, 2023, 7:29 p.m. UTC | #1

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. 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.. so we assume veth
is first created and then moved, or we don't use veth, or I'm lost
completely?

Paolo Abeni Feb. 15, 2023, 8:33 p.m. UTC | #2

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

Jakub Kicinski Feb. 15, 2023, 11:05 p.m. UTC | #3

On Wed, 15 Feb 2023 21:33:01 +0100 Paolo Abeni wrote:
> 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.

I see your point now. Must have been low on coffee in the morning.
Thanks!