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 B50C01FF09C for ; Mon, 19 Oct 2026 13:27:35 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id E76732164C; Mon, 19 Oct 2026 13:27:33 +0200 (CEST) Message-ID: <1947384b-d89a-49ef-a221-33c51c14dee0@proxmox.com> Date: Mon, 19 Oct 2026 13:27:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: superseded: [PATCH common/network 0/3] Performance improvements for applying VLAN / QinQ zones To: pve-devel@lists.proxmox.com References: <20260709132857.239615-1-s.hanreich@proxmox.com> Content-Language: en-US From: Stefan Hanreich In-Reply-To: <20260709132857.239615-1-s.hanreich@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.421 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: P66H6KTUXQHXVPRC4TWTPUSLQPERRJAI X-Message-ID-Hash: P66H6KTUXQHXVPRC4TWTPUSLQPERRJAI 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: 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(-) >