为什么 DPDK VirtIO 只能跑到 40Gbps？—— 一次 KVM 虚拟交换机性能瓶颈定位全过程（下）

接上文：为什么 DPDK VirtIO 只能跑到 40Gbps？—— 一次 KVM 虚拟交换机性能瓶颈定位全过程（上）-CSDN博客

七、Split Virtqueue：为什么一个队列要维护三张环？

定位到 Virtqueue 之后，我们继续深入分析。

很多开发者第一次看到 VirtIO 的数据结构都会疑惑：

为什么普通网卡只有一个 Descriptor Ring，而 VirtIO 却维护三张 Ring？

实际上，在Split Virtqueue中，真正的数据结构包括：

Descriptor Table + Available Ring + Used Ring

三者职责完全不同。

整体关系如下：

Guest Driver │ ▼ Descriptor Table （描述Buffer地址） │ ▼ Available Ring （告诉Host哪些Descriptor可以用了） │ ▼ Host(vhost) 处理数据 │ ▼ Used Ring （告诉Guest哪些Descriptor已经处理完成）

这里最重要的一点是：Descriptor Table 本身不会通知任何人。

真正负责"发布"消息的是：

avail->idx

以及：

used->idx

直到这里。

我们才真正理解：

为什么上一篇 Memory Ordering 会如此重要。

VirtIO 的整个同步机制，本质上也是：

先构造对象，再发布 Index。

八、为什么小包性能下降如此明显？

继续分析 Perf。

我们发现：

64Byte包CPU大量时间花在：

virtqueue_notify() ↓ eventfd_write() ↓ KVM ↓ VM Exit

为什么？

假设Burst只有：

1 Packet

流程：

Guest ↓ Descriptor ↓ avail->idx++ ↓ Kick ↓ VM Exit ↓ Host 处理 ↓ Notify ↓ VM Entry ↓ 继续

一次Packet。

一次VM Exit。

一次VM Entry。

CPU大量时间浪费在虚拟化切换。

而1500Byte情况不同。

虽然Packet数量减少。

但是每个Packet携带的数据更多。

最终100Gbps对应PPS大幅下降。

例如：

也就是说：

VirtIO真正限制的是PPS。

不是Gbps。

九、Event Index：VirtIO 最大的优化之一

Linux VirtIO 后来增加了：

Event Index

很多人觉得只是一个Flag。

实际上：

它改变了整个Notification模型。

传统模式：

每次 avail++ ↓ Kick

Host不停收到Notify。

CPU不断VM Exit Event Index则变成：

Burst 32 Packet ↓ 一次 Kick

Host收到一次Notification。

继续处理32 个Descriptor。

CPU VM Exit次数下降几十倍。

很多云厂商VirtIO性能能够突破80Gbps。

最重要原因之一就是Event Index。

十、Packed Virtqueue 为什么越来越流行？

虽然Split Virtqueue已经使用很多年。

但是：

越来越多的新平台开始默认Packed Virtqueue。

原因只有两个字：

Cache。

Split模式需要CPU不停访问：

Descriptor ↓ Available Ring ↓ Used Ring

三个不同区域。

CPUCache不断Miss。

Packed则把Descriptor状态直接放在同一结构。

例如：

Descriptor Flags Wrap Counter

CPU几乎连续访问内存。

Cache命中率显著提高。

不仅减少Cache Miss。

同时减少Memory Barrier。

因此新版本VirtIO几乎全部推荐Packed。

十一、DPDK vhost-user 为什么还能继续优化？

很多人认为开启vhost-user性能已经最佳。

实际上DPDK还做了很多优化。

例如：

批量处理Descriptor。

不是：

1 Packet ↓ 1 Descriptor

而是：

Burst32 ↓ 32 Descriptor

随后统一更新：

used->idx

统一Kick。

这样：

Notification次数再次下降。

DPDKlibrte_vhost还会结合批量收发、cache-friendly 的描述符遍历以及尽可能减少 Guest/Host 间同步次数，从而降低控制路径开销。

十二、问题最终是如何解决的？

最终整个系统进行了如下优化：

①开启：Packed Virtqueue。

②开启：Event Index。

③Burst由：

16 ↓ 32

④Guest：开启Multi Queue。

⑤Host：每个Queue绑定独立PMD。

再次测试结果如下：

可以看到：

CPU反而更忙。

但是：

吞吐提升超过2 倍。

真正说明：

以前CPU不是处理Packet。

而是浪费在Notification。

十三、生产环境有哪些经验？

经过这次故障。

团队总结了几条经验。

① 不要只盯着 PMD

VirtIO瓶颈很多发生在控制路径。

不是DMA。

不是Descriptor。

而是Notification。

② PPS 比 Gbps 更重要

很多100G测试都是1500Byte。

实际上真正决定VirtIO性能的是PPS。

尤其64Byte。

③ Event Index 建议开启

如果业务允许批量发送。

Event Index收益非常明显。

不过也要注意，批量通知会增加一定的数据包完成延迟，因此需要根据业务对时延和吞吐的要求进行权衡。

④ 优先使用 Packed Virtqueue

对于支持 VirtIO 1.1 及以上的平台，Packed Virtqueue 通常能带来更好的缓存局部性和更低的同步开销，是值得优先考虑的选择。

⑤ Host 和 Guest 要共同优化

VirtIO不是Host一个人的事情。

Guest、Burst、Queue、Affinity。

都会影响最终性能。

总结

回到文章开头的问题：

为什么 DPDK VirtIO 只能跑到 40Gbps？

很多团队最初都会怀疑：

• PMD 不够快；
• RSS 不均衡；
• Descriptor 太少；
• HugePage 配置错误；
• CPU 性能不足。

但真正的问题往往隐藏在更深的地方。

在 VirtIO 架构中，数据真正走的是共享内存，而性能瓶颈常常来自控制路径——Descriptor 发布、Kick、Notify、Event Index、VM Exit 等同步机制。

尤其是在 64Byte 小包场景下，PPS 极高，每一次 Notification 的成本都会被无限放大。当通知过于频繁时，CPU 花费的大量时间并不是转发数据，而是在 Guest、KVM、vhost-user 和 Host 之间不断切换。

因此，一个高性能的 VirtIO 系统，不只是需要优秀的 DPDK 数据平面，更需要合理设计通知机制、队列模型和批处理策略。

真正理解 Virtqueue 的工作原理之后，再去分析 vhost-user、Packed Virtqueue、vDPA，甚至硬件 VirtIO 加速，就会发现它们都在围绕同一个目标进行优化：

减少同步，减少通知，减少切换，让 CPU 更多时间用于真正的数据转发，而不是控制路径。