netdev - Re: [PATCH RFC net-next] net: cache the __dev_alloc

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <03c25d8e994e4388cb8bfd726ba738eea3c4dcdf.camel@redhat.com>
Date: Tue, 07 May 2024 09:26:26 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: William Tu <witu@...dia.com>, netdev@...r.kernel.org
Cc: jiri@...dia.com, bodong@...dia.com, kuba@...nel.org
Subject: Re: [PATCH RFC net-next] net: cache the __dev_alloc_name()

On Mon, 2024-05-06 at 20:32 +0000, William Tu wrote:
> When a system has around 1000 netdevs, adding the 1001st device becomes
> very slow. The devlink command to create an SF
>   $ devlink port add pci/0000:03:00.0 flavour pcisf \
>     pfnum 0 sfnum 1001
> takes around 5 seconds, and Linux perf and flamegraph show 19% of time
> spent on __dev_alloc_name() [1].
> 
> The reason is that devlink first requests for next available "eth%d".
> And __dev_alloc_name will scan all existing netdev to match on "ethN",
> set N to a 'inuse' bitmap, and find/return next available number,
> in our case eth0.
> 
> And later on based on udev rule, we renamed it from eth0 to
> "en3f0pf0sf1001" and with altname below
>   14: en3f0pf0sf1001: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
>       altname enp3s0f0npf0sf1001
> 
> So eth0 is actually never being used, but as we have 1k "en3f0pf0sfN"
> devices + 1k altnames, the __dev_alloc_name spends lots of time goint
> through all existing netdev and try to build the 'inuse' bitmap of
> pattern 'eth%d'. And the bitmap barely has any bit set, and it rescanes
> every time.
> 
> I want to see if it makes sense to save/cache the result, or is there
> any way to not go through the 'eth%d' pattern search. The RFC patch
> adds name_pat (name pattern) hlist and saves the 'inuse' bitmap. It saves
> pattens, ex: "eth%d", "veth%d", with the bitmap, and lookup before
> scanning all existing netdevs.

An alternative heuristic that should be cheap and possibly reasonable
could be optimistically check for <name>0..<name><very small int>
availability, possibly restricting such attempt at scenarios where the
total number of hashed netdevice names is somewhat high.

WDYT?

Cheers,

Paolo