netdev - Re: [PATCH net-next] rtnetlink: Support fine-grained netdevice bulk deletion

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]

Date:   Wed, 24 Nov 2021 18:59:42 +0200
From:   Gilad Naaman <gnaaman@...venets.com>
To:     kuba@...nel.org
Cc:     dsahern@...il.com, lschlesinger@...venets.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next] rtnetlink: Support fine-grained netdevice bulk deletion

> I'm sorry I don't understand. Please provide a clear use case.
> I've never heard of "factory default on a large server".

Our company is developing a core-router that is supposed to support thousands
of links, both physical and virtual. (e.g. loopbacks, tunnels, vrfs, etc)

At times we are required to configure massive amounts of interfaces at once,
such as when a factory reset is performed on the router (causing a deletion
of all links), a configuration is restored after an upgrade,
or really whenever the system reboots.

The significant detail in Lahav's benchmark is not "deleting 10K loopbacks",
it's "deleting 10K interfaces", which *is* a good representation of what we're
trying to do.

> <snipped> I've spent a month
> cleaning up after your colleague who decided to put netdev->dev_addr 
> on a tree, would be great to understand what your needs are before we
> commit more time.

I apologize for any time spent over this; this is absolutely not what I had in
mind or what I magined would happen.
It was not my intention to cause any grief.

The problematic patch (406f42fa0d3cbcea3766c3111d79ac5afe711c5b) I sent has 
another example of our use case.
The numbers used there, 1500 vlans, were not arbitrary chosen for the benchmark,
but are derived from actual workloads which we have encountered.

I apologize if these patches seemed disconnected from real world use.