From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>,
"ryosuke.nakayama@ryskn.com" <ryosuke.nakayama@ryskn.com>
Subject: Re: [RFC PATCH 0/2] network: add VPP (fd.io) as alternative dataplane
Date: Tue, 17 Mar 2026 10:18:48 +0000 [thread overview]
Message-ID: <e53eca603f839a2d07a8cf4a5bc5c09622736202.camel@groupe-cyllene.com> (raw)
In-Reply-To: <20260316222816.42944-1-ryosuke.nakayama@ryskn.com>
Hi,
thanks for your work on this !
Could it be possible to write a small Howto to install vpp
software itself + bridge configuration ?
Alexandre
-------- Message initial --------
De: Ryosuke Nakayama <ryosuke.nakayama@ryskn.com>
À: pve-devel@lists.proxmox.com
Objet: [RFC PATCH 0/2] network: add VPP (fd.io) as alternative
dataplane
Date: 16/03/2026 23:28:14
From: ryskn <ryosuke.nakayama@ryskn.com>
This RFC series integrates VPP (Vector Packet Processor, fd.io) as an
optional userspace dataplane alongside OVS in Proxmox VE.
VPP is a DPDK-based, userspace packet processing framework that
provides VM networking via vhost-user sockets. It is already used in
production by several cloud/telecom stacks. The motivation here is to
expose VPP bridge domains natively in the PVE WebUI and REST API,
following the same pattern as OVS integration.
Background and prior discussion:
Note: the benchmark figures quoted in that forum thread are slightly
off due to test configuration differences. Please use the numbers in
this cover letter instead.
--- What the patches do ---
Patch 1 (pve-manager):
- Detect VPP bridges via 'vppctl show bridge-domain' and expose
them as type=VPPBridge in the network interface list
- Create/delete VPP bridge domains via vppctl
- Persist bridge domains to /etc/vpp/pve-bridges.conf (exec'd at
VPP startup) so they survive reboots
- Support vpp_vlan_aware flag (maps to bridge-domain learn flag)
- VPP VLAN subinterface create/delete/list, persisted to
/etc/vpp/pve-vlans.conf
- Exclude VPP bridges from the SDN-only access guard so they appear
in the WebUI NIC selector
- Vhost-user socket convention:
/var/run/vpp/qemu-<vmid>-<net>.sock
- pve8to9: add upgrade checker for VPP dependencies
Patch 2 (proxmox-widget-toolkit):
- Add VPPBridge/VPPVlan to network_iface_types (Utils.js)
- NetworkView: VPPBridge and VPPVlan entries in the Create menu;
render vlan-raw-device in Ports/Slaves column for VPPVlan;
vpp_vlan_aware support in VLAN aware column
- NetworkEdit: vppbrN name validator; vpp_bridge field for VPPVlan;
hide MTU/Autostart/IP fields for VPP types; use VlanName vtype
for VPPVlan (allows dot notation, e.g. tap0.100)
--- Testing ---
Due to the absence of physical NICs in my test environment, all
benchmarks were performed as VM-to-VM communication over the
hypervisor's virtual switch (vmbr1 or VPP bridge domain). These
results reflect the virtual switching overhead, not physical NIC
performance, where VPP's DPDK polling would show a larger advantage.
Host: Proxmox VE 8.x (Intel Xeon), VMs: Debian 12 (virtio-net q=1)
VPP: 24.06, coalescing: frames=32 time=0.5ms, polling mode
iperf3 / netperf (single queue, VM-to-VM):
Metric vmbr1 VPP (vhost-user)
iperf3 31.0 Gbits/s 13.2 Gbits/s
netperf TCP_STREAM 32,243 Mbps 13,181 Mbps
netperf TCP_RR 15,734 tx/s 989 tx/s
VPP's raw throughput is lower than vmbr1 in this VM-to-VM setup due
to vhost-user coalescing latency. Physical NIC testing (DPDK PMD) is
expected to close or reverse this gap.
gRPC (unary, grpc-flow-bench, single queue, VM-to-VM):
Flows Metric vmbr1 VPP
100 RPS 32,847 39,742
100 p99 lat 7.28 ms 6.16 ms
1000 RPS 40,315 41,139
1000 p99 lat 48.96 ms 31.96 ms
VPP's userspace polling removes kernel scheduler jitter, which is
visible in the gRPC latency results even in the VM-to-VM scenario.
--- Known limitations / TODO ---
- No ifupdown2 integration yet; VPP config is managed separately via
/etc/vpp/pve-bridges.conf and pve-vlans.conf
- No live migration path for vhost-user sockets (sockets must be
pre-created on the target host)
- OVS and VPP cannot share the same physical NIC in this
implementation
- VPP must be installed and running independently (not managed by PVE)
--- CLA ---
Individual CLA has been submitted to office@proxmox.com.
---
ryskn (2):
api: network: add VPP (fd.io) dataplane bridge support
ui: network: add VPP (fd.io) bridge type support
PVE/API2/Network.pm | 413 ++++++++++++++++++++++++++-
PVE/API2/Nodes.pm | 19 ++
PVE/CLI/pve8to9.pm | 48 ++++
www/manager6/form/BridgeSelector.js | 5 +
www/manager6/lxc/Network.js | 34 +++
www/manager6/node/Config.js | 1 +
www/manager6/qemu/NetworkEdit.js | 27 ++
www/manager6/window/Migrate.js | 48 ++++
src/Utils.js | 2 +
src/node/NetworkEdit.js | 64 ++++-
src/node/NetworkView.js | 35 +++
11 files changed, 675 insertions(+), 21 deletions(-)
next prev parent reply other threads:[~2026-03-17 10:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-16 22:28 Ryosuke Nakayama
2026-03-16 22:28 ` [RFC PATCH manager 1/2] api: network: add VPP (fd.io) dataplane bridge support Ryosuke Nakayama
2026-03-16 22:28 ` [RFC PATCH widget-toolkit 2/2] ui: network: add VPP (fd.io) bridge type support Ryosuke Nakayama
2026-03-17 6:39 ` [RFC PATCH 0/2] network: add VPP (fd.io) as alternative dataplane Stefan Hanreich
2026-03-17 10:18 ` DERUMIER, Alexandre [this message]
2026-03-17 11:14 ` Ryosuke Nakayama
2026-03-17 11:14 ` [RFC PATCH qemu-server 1/2] qemu: add VPP vhost-user dataplane support Ryosuke Nakayama
2026-03-17 11:14 ` [RFC PATCH qemu-server 2/2] qemu: VPP: clean up vhost-user interfaces on stop, fix tx_queue_size Ryosuke Nakayama
2026-03-17 11:26 ` [RFC PATCH qemu-server 1/2] qemu: add VPP vhost-user dataplane support Ryosuke Nakayama
2026-03-17 11:21 ` [RFC PATCH 0/2] network: add VPP (fd.io) as alternative dataplane Ryosuke Nakayama
2026-03-17 11:21 ` [RFC PATCH pve-common] network: add VPP bridge helpers for vhost-user dataplane Ryosuke Nakayama
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=e53eca603f839a2d07a8cf4a5bc5c09622736202.camel@groupe-cyllene.com \
--to=alexandre.derumier@groupe-cyllene.com \
--cc=pve-devel@lists.proxmox.com \
--cc=ryosuke.nakayama@ryskn.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox