netdev - Re: RFC: Should net namespaces scale up (>10k) ?

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: <0df1bf91-7473-4ab4-9a96-8eec4c7fa5c8@intel.com>
Date: Tue, 17 Sep 2024 08:40:45 +0200
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Alexandre Ferrieux <alexandre.ferrieux@...il.com>, Simon Horman
	<horms@...nel.org>
CC: Eric Dumazet <edumazet@...gle.com>, <netdev@...r.kernel.org>, Tony Nguyen
	<anthony.l.nguyen@...el.com>, "Knitter, Konrad" <konrad.knitter@...el.com>
Subject: Re: RFC: Should net namespaces scale up (>10k) ?

On 9/17/24 00:05, Alexandre Ferrieux wrote:
> On 16/09/2024 16:01, Simon Horman wrote:
>>
>>>> Any insight on the (possibly very good) reasons those two apparent
>>>> warts stand in the way of netns scaling up ?
>>>
>>> I guess that the reason is more pragmatic, net namespaces are decade
>>> older than xarray, thus list-based implementation.
>>
>> Yes, I would also guess that the reason is not that these limitations were
>> part of the design. But just that the implementation scaled sufficiently at
>> the time. And that if further scale is required, then the implementation
>> can be updated.
> 
> Okay, thank you for confirming my fears :}
> Now, what shall we do:
> 
>   1. Ignore this corner case and carve the "few netns" assumption in stone;
> 
>   2. Migrate netns IDs to xarrays (not to mention other leftover uses of IDR).
> 
> Note that this funny workload of mine is a typical situation where the "DPDK
> beats Linux" myth gets reinforced. I find this pretty disappointing, as it
> implies reinventing the whole network stack in userspace. All the more so, as
> the other typical case for DPDK is now moot thanks to XDP.
> 
> What do you think ?

I would describe (here) more what is this typical scenario where users
bother to set up DPDK for perf gains.

With that I think that is a legitimate reason to rewrite parts of netns,
if only to allow companies to shuffle engineers out from DPDK-support
teams into upstream-related ones :) [in the long term ofc]