From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 1AC1C1FF09C for ; Mon, 19 Oct 2026 13:27:16 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 894D2216B9; Mon, 19 Oct 2026 13:26:54 +0200 (CEST) From: Stefan Hanreich To: pve-devel@lists.proxmox.com Subject: [PATCH common/network v2 0/3] Performance improvements for applying VLAN / QinQ zones Date: Mon, 19 Oct 2026 13:26:33 +0200 Message-ID: <20261019112640.181849-1-s.hanreich@proxmox.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1792409207845 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.436 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: T4OYVCTCAJ7FQTLS62YIVGSOSF7U7YIQ X-Message-ID-Hash: T4OYVCTCAJ7FQTLS62YIVGSOSF7U7YIQ X-MailFrom: s.hanreich@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ## 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. Changes from v1 -> v2: * ran make tidy 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(-) -- Generated by murpp 0.12.0