Ситуация: у нас работают KVM-виртуалки на Debian/bullseye в Proxmox/PVE с 10Gb-сетевыми интерфейсами, но при высокой сетевой нагрузке (RTP/UDP) через virtio-net наблюдаются потери пакетов. Такая же проблема есть и на кластерах VMware. Там предлагают решение: увеличить размеры ring-буферов (см. https://kb.vmware.com/s/article/50121760), и проблема с потерями пакетов пропадает (мы сами проверяли).

Теперь хотелось бы сделать то же самое для virtio-net в PVE KVM, но, к сожалению, пока это не поддерживается:  
# ethtool -G neth1 rx 4048 tx 4048  
netlink error: Operation not supported

Чтобы избежать побочных эффектов, в тестовой среде мы запускаем по одной выделенной гостевой ВМ на каждый гипервизор. Для гостя используем отдельный бридж, подключённый ко второму порту Intel X722 10G NIC. Пример конфигурации такой ВМ:  

root@pve-test-00:~# qm config 100  
boot: order=scsi0;ide2;net0  
cores: 16  
cpu: host  
ide2: none,media=cdrom  
machine: q35  
memory: 52048  
meta: creation-qemu=6.2.0,ctime=1661099025  
name: Sp1  
net0: virtio=C2:50:0E:F5:6E:BC,bridge=vmbr1,queues=4,tag=3762  
net1: virtio=56:4C:C5:75:7D:79,bridge=vmbr1,firewall=1,tag=901  
numa: 0  
ostype: l26  
scsi0: local-btrfs:100/vm-100-disk-0.raw,size=320G  
scsihw: virtio-scsi-pci  
smbios1: uuid=3a55db64-5fea-4165-bcf1-a640b0caf909  
sockets: 1  
vmgenid: f280627f-b65d-4b7d-b841-1966d64f7ff9  

NIC на хосте поддерживает мультиочереди (пробовали разные значения, но ситуация не меняется):  

root@pve-test-00:~# ethtool -l eno2  
Channel parameters for eno2:  
Pre-set maximums:  
RX:             n/a  
TX:             n/a  
Other:          1  
Combined:       32  
Current hardware settings:  
RX:             n/a  
TX:             n/a  
Other:          1  
Combined:       20  

Размер RX буфера на NIC гипервизора можно менять (хотя это особо не влияет на потерю пакетов):  

root@pve-test-00:~# ethtool -g eno2  
Ring parameters for eno2:  
Pre-set maximums:  
RX:             4096  
RX Mini:        n/a  
RX Jumbo:       n/a  
TX:             4096  
Current hardware settings:  
RX:             2048  
RX Mini:        n/a  
RX Jumbo:       n/a  
TX:             2048  

Используем свежий PVE:  

root@pve-test-00:~# pveversion  
pve-manager/7.2-7/d0dd0e85 (running kernel: 5.15.39-3-pve)  

root@pve-test-00:~# uname -a  
Linux pve-test-00 5.15.39-3-pve #2 SMP PVE 5.15.39-3 (Wed, 27 Jul 2022 13:45:39 +0200) x86_64 GNU/Linux  

Характеристики хоста: Lenovo SN550, процессор Intel® Xeon® Silver 4210R @ 2.40GHz с поддержкой HT, 64 Гб ОЗУ, SSD 480 Гб Micron SATA, сетевой контроллер Ethernet Connection X722 10GbE (i40e).  

Мы знаем, что подобные проблемы были у некоторых и в 2014 году (см. https://groups.google.com/g/snabb-devel/c/ng78LbcaFgI?pli=1). Интересно, не одни ли мы в 2022 замечаем такие проблемы с производительностью и потерями пакетов?  

Также известно, что при использовании SR-IOV проблема с потерями уходит, но мы хотим избежать минусов SR-IOV и ищем способ получить высокую сетевую нагрузку с virtio-net, чтобы понять, в чем ограничение.  

Рассматривали вариант увеличить жёстко заданные в qemu значения VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE/VIRTIO_NET_TX_QUEUE_DEFAULT­_SIZE в hw/net/virtio-net.c с 256 до большего числа. Кто-то уже пытался это сделать (https://github.com/qemu/qemu/pull/115), но патч так и не вышел в основную ветку, а прежде чем тратить силы дальше, хотелось бы понять, правильно ли мы на это смотрим или что-то упускаем?  

Есть ли у кого-то похожие проблемы или советы, как с этим бороться? Может, проблема в Linux бридже, и использование OpenVSwitch могло бы помочь? Что еще можно попробовать?