From: Stefan Hanreich <s.hanreich@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: superseded: [PATCH common/network 0/3] Performance improvements for applying VLAN / QinQ zones
Date: Mon, 19 Oct 2026 13:27:29 +0200 [thread overview]
Message-ID: <1947384b-d89a-49ef-a221-33c51c14dee0@proxmox.com> (raw)
In-Reply-To: <20260709132857.239615-1-s.hanreich@proxmox.com>
https://lore.proxmox.com/pve-devel/20261019112640.181849-2-s.hanreich@proxmox.com/T/#t
On 7/9/26 3:28 PM, Stefan Hanreich wrote:
> ## Problem
>
> When creating a VLAN / QinQ zone on a non VLAN-aware bridge, the SDN config
> generation enters a code path that calls ip_link_details from PVE::IPRoute2
> repeatedly. This causes a severe slowdown when applying configurations with a
> large amount of VNets. What exacerbated this problem was that, aside from
> calling iproute2 twice, every vnet recalculated the bridge ports for its bridge
> by iterating over all existing interfaces on the host which leads to a quadratic
> increase in runtime once the SDN configuration had been applied once.
>
> ## Solution
>
> This patch series introduces a new helper to pve-common that pre-computes the
> bridge port mappings used in the SDN config generation. The SDN stack then calls
> that function once at the beginning of the 'Apply' step, then re-uses the result
> for each vnet. This avoids calling iproute2 repeatedly and the nested loop
> inside the generate_sdn_config function in the VLAN / QinQ plugins.
>
> An initial approach only cached the ip_link_details output and reused that, but
> this approach did not avoid the nested loops, so I opted for pre-calculating the
> required information instead and passing only that to the zone plugins. The
> first patch is a remnant of the initial approach, which was still included
> because it is useful for the other callsites.
>
> ## Benchmarks
>
> This slashes the runtime for generating the SDN configuration considerably on a
> test setup with 1000 VLAN VNets present on the host / config:
>
> Without these patches applied:
>
> root@pve-vlan-test:~# time perl -e 'use PVE::Network::SDN; PVE::Network::SDN::generate_raw_etc_network_config(PVE::Network::SDN::compile_running_cfg(1))'
> real 5m59.853s
> user 5m49.009s
> sys 0m34.887s
>
> With these patches applied:
>
> root@pve-vlan-test:~# time perl -e 'use PVE::Network::SDN; PVE::Network::SDN::generate_raw_etc_network_config(PVE::Network::SDN::compile_running_cfg(1))'
> real 0m0.868s
> user 0m0.818s
> sys 0m0.109s
>
> ## Future Work
>
> This patch series does not address any bottlenecks in ifupdown2, which is now
> the limiting factor when applying large configurations. Applying a SDN
> configuration via ifreload with 1000 VLANs takes 22 seconds. I'll be exploring
> potential improvements there with Christoph, but currently we do not have high
> hopes of improving the runtime there considerably.
>
> Currently the SDN configuration is applied sequentially on each node, I'll be
> looking into creating a patch series that applies the network configuration in
> parallel.
>
>
> pve-common:
>
> Stefan Hanreich (2):
> iproute2: restructure get_physical_bridge_ports
> iproute2: add helper for getting bridge port mappings
>
> src/PVE/IPRoute2.pm | 30 +++++++++++++++++++++++++++---
> 1 file changed, 27 insertions(+), 3 deletions(-)
>
>
> pve-network:
>
> Stefan Hanreich (1):
> fix #7738: zones: use pre-computed bridge port list
>
> src/PVE/Network/SDN/Zones.pm | 3 +++
> src/PVE/Network/SDN/Zones/Plugin.pm | 7 +------
> src/PVE/Network/SDN/Zones/QinQPlugin.pm | 5 +++--
> src/PVE/Network/SDN/Zones/VlanPlugin.pm | 5 +++--
> src/test/run_test_zones.pl | 13 ++++++++++---
> 5 files changed, 20 insertions(+), 13 deletions(-)
>
>
> Summary over all repositories:
> 6 files changed, 47 insertions(+), 16 deletions(-)
>
prev parent reply other threads:[~2026-10-19 11:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 13:28 [PATCH common/network 0/3] Performance improvements for applying VLAN / QinQ zones Stefan Hanreich
2026-07-09 13:28 ` [PATCH pve-common 1/3] iproute2: restructure get_physical_bridge_ports Stefan Hanreich
2026-07-27 16:13 ` Lukas Sichert
2026-09-18 9:04 ` Gabriel Goller
2026-07-09 13:28 ` [PATCH pve-common 2/3] iproute2: add helper for getting bridge port mappings Stefan Hanreich
2026-07-28 12:00 ` Lukas Sichert
2026-07-09 13:28 ` [PATCH pve-network 3/3] fix #7738: zones: use pre-computed bridge port list Stefan Hanreich
2026-07-28 11:58 ` Lukas Sichert
2026-09-18 9:04 ` [PATCH common/network 0/3] Performance improvements for applying VLAN / QinQ zones Gabriel Goller
2026-09-18 9:27 ` Gabriel Goller
2026-10-19 11:27 ` Stefan Hanreich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1947384b-d89a-49ef-a221-33c51c14dee0@proxmox.com \
--to=s.hanreich@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.