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: <3e2420e7-02ae-4957-ab6c-12d2442e0a99@orange.com>
Date: Tue, 17 Sep 2024 13:06:25 +0200
From: Alexandre Ferrieux <alexandre.ferrieux@...il.com>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>,
 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>, nicolas.dichtel@...nd.com
Subject: Re: RFC: Should net namespaces scale up (>10k) ?

On 17/09/2024 08:40, Przemek Kitszel wrote:
> On 9/17/24 00:05, Alexandre Ferrieux wrote:
>> 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.

Two cases from my experience:

(1) "Bump-in-the-wire" rx/tx on same port, trying to reach line-rate on one or
several 100Gbps interfaces. On this one, Linux performs beautifully, with "no
fat", just use XDP (verdict XDP_TX) along with some packet tweaking in a kfunc.
Of course you need to get queue number, coalescence, IRQ and NUMA right. And you
need a well-written native-XDP mode in the driver (not all NICs have one).
Here, the "DPDK advantage" is a lie.

(2) "Many-tunnels" as in my CGNAT tester case. Due to the limitations we are
talking about, people are right (so far) to turn to DPDK, as they do for example
in TRex https://trex-tgn.cisco.com/ .

> 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]

I violently agree :)