Description
In high-throughput container networking scenarios, single-queue TAP devices act as a CPU bottleneck because all packets must be processed sequentially by a single core. Modern hypervisors like QEMU and Cloud Hypervisor support multi-queue TAP devices to match guest virtual network interface queues to host CPU cores. Currently, urunc's network setup hardcodes Queues: 1 inside createTapDevice, which limits network scalability.
Suggested Implementation:
- Configurable Queues: Introduce a configuration field in urunc's config file and container annotations (e.g., urunc.io/net-queues) to specify network queue counts.
- Multi-FD Setup: Modify createTapDevice to allocate multiple file descriptors when multiqueue is enabled, and update ownership/permissions for all allocated queues.
- VMM CLI Config: Propagate the multiple TAP queue parameters to the QEMU/Cloud Hypervisor argument builders.
System info
- Urunc version: main
- Arch: x86_64, arm64
- VMM: QEMU, Cloud Hypervisor
- Unikernel: All
Steps to reproduce
- Run a network intensive workload using urunc with QEMU/Cloud Hypervisor.
- Observe single-queue TAP device bottleneck on host CPU.
Description
In high-throughput container networking scenarios, single-queue TAP devices act as a CPU bottleneck because all packets must be processed sequentially by a single core. Modern hypervisors like QEMU and Cloud Hypervisor support multi-queue TAP devices to match guest virtual network interface queues to host CPU cores. Currently, urunc's network setup hardcodes Queues: 1 inside createTapDevice, which limits network scalability.
Suggested Implementation:
System info
Steps to reproduce