通用负载场景下OVS-DPDK性能不足及队列利用率低问题咨询

OVS+DPDK对当前云场景的价值 #

OVS+DPDK并非对你的场景没有价值。SRIOV虽然在直通场景下性能表现优异，但缺少OVS原生的灵活流量编排能力，包括安全组、QoS限速、流量镜像、Overlay网络封装/解封装等高级网络特性，上述特性在云场景中是刚需，而OVS+DPDK是兼顾网络灵活性与转发性能的成熟方案，你当前的性能问题是配置未对齐导致的，并非方案本身缺陷。

RXQ队列含义与单队列被使用的原因 #

队列含义 #

你观察到的queue-id 0-8是DPDK物理网卡的接收队列（RXQ），网卡通过RSS（接收侧扩展）技术，基于报文的源目IP、源目端口等字段做哈希，将不同流量分发到不同RXQ，每个RXQ对应一个独立的PMD处理核心，从而实现转发性能的线性扩展。

单队列被使用的常见原因 #

• 压测流量为单流UDP RTP：RSS的哈希分发规则对单流流量只会返回唯一的哈希结果，因此所有流量只会落到固定的一个队列上，其余队列自然无流量
• 全链路多队列配置未打通：物理DPDK端口、vhost-user端口、虚拟机virtio-net三层只要有任意一层未开启多队列配置，都会导致流量只能走单队列
• PMD核心绑定配置错误：未给每个RXQ分配独立的、隔离的PMD处理核心，导致队列无法正常调度

PMD负载指标说明 #

pmd-stats-show中74.96%的processing cycles属于高负载状态，该指标代表PMD核心花费在报文处理上的时间占比，你当前所有流量都由单个PMD核心处理，150字节小包场景下200kpps的流量已经接近单个核心的处理上限，再提升流量就会出现队列溢出丢包，和你观察到的卡顿现象完全吻合。

通用负载场景OVS+DPDK性能优化方案 #

• 打通全链路多队列配置
  • 物理DPDK端口配置多队列与RSS：执行ovs-vsctl set Interface dpdk0 options:n_rxq=8，同时配置RSS哈希字段覆盖UDP源目端口，保证多流场景下流量均匀分发到所有队列
  • vhost-user端口配置多队列：创建虚拟机时给对应vhost端口配置队列数，建议和虚拟机vCPU数量对齐，配置命令参考ovs-vsctl set Interface <vhost端口名> options:n_rxq= <队列数>
  • 虚拟机内部开启virtio-net多队列：libvirt配置中添加<driver name='vhost' queues='N'/>参数，N为队列数，和vCPU数保持一致，或者加载virtio_net内核模块时添加queues=N参数
• 优化PMD核心亲和性
  • 内核启动参数添加isolcpus=<核心列表> nohz_full=<核心列表> rcu_nocbs=<核心列表>，将用于PMD的核心从内核调度中隔离，避免被其他进程抢占资源
  • 执行ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=<核心掩码>，给OVS分配已隔离的PMD核心，保证每个RXQ对应一个独立的PMD核心
• 小包场景专项优化
  • 关闭vhost-user端口不必要的卸载特性，执行ovs-vsctl set Interface <vhost端口名> options:tx_tcp_seg=0 options:tx_udp_seg=0，避免TSO/GSO等大包卸载特性增加小包处理开销
  • 升级OVS与DPDK版本，当前使用的OVS 2.13、DPDK 19.11属于较老的LTS版本，后续版本对vhost-user转发性能有大量优化，建议升级到OVS 2.17 + DPDK 21.11的LTS版本组合
  • 压测时使用多流UDP RTP流量，模拟实际生产环境多用户的流量特征，即可用到所有RXQ队列的处理能力，充分发挥DPDK的百万级pps转发性能

内容的提问来源于stack exchange，提问作者Satish