本文描述了“vHost User NUMA感知”的概念，该特性的测试表现，以及该特性为ovs+dpdk带来的性能提升。本文的目标受众是那些希望了解ovs+dpdk底层细节的人，如果你正在使用ovs+dpdk在NUMA host上配置虚拟化平台，使用vHost User类型的port作为guest的虚拟网络配置，那么本文或许会给你一些优化性能的灵感。
vHost User NUMA感知
vHost User NUMA感知特性在DPDK 2.2版本时引入，该特性的引入是为了解决DPDK中的一个拖后腿的地方：在多NUMA节点的环境中使用DPDK，vHost的内存分配效率比较低。为了了解这个拖后腿的点，我们先必须了解vHost User设备使用的三种内存：
- 由DPDK分配管理的内存，Device tracking memory
- 由OVS分配管理的内存，mbufs
- 由QEMU管理分配的内存，Guest memory(device and memory buffers)
在多NUMA节点环境中，显然如果要优化性能，这三种内存应当分配在同一个NUMA节点上。但就这个小小的要求，在DPDK 2.2版本之前都是不可能达到的，因为在2.2版本之前，所有由DPDK分配管理的Device tracking memory内存，都来自同一个NUMA节点，即便使用这些内存的vHost User设备被其它NUMA节点上跑着的虚拟机使用着。这就会有一种尴尬的场景出现：一台虚拟机，QEMU为它分配的guest memory在节点A上，而DPDK的device tracking memory在另外一个节点B上。这种尴尬的场景会直接导致Intel QuickPath Interconnect(QPI)堵车，显然也会有其它方面潜在的性能损耗。这个场景的示意图如下：
在DPDK 2.2版本之后，DPDK中的vHost结构被优化成了动态的与QEMU管理的guest memory贴在一起。这时，当一个vHost设备出生的时候，DPDK为它分配的内存不再固定，变得有点像一个临时内存区，这个vHost设备将在这个临时内存区开心的活着，直到QEMU通知DPDK：“嘿，小同志，我需要一个vHost设备”。当QEMU向DPDK索取一个vHost设备的时候，显然QEMU需要向DPDK发送消息，而DPDK就可以利用这个消息去确定这个索要vHost设备的虚拟机位于哪个NUMA节点，之后，这个vHost设备的内存也将迁移至这个NUMA节点上。
换句话说，vHost设备出生时居住在一个临时住所，直至QEMU前来领养它，之后它才有一个稳定的家。
现在我们解决了2/3的问题，还有一部分内存上文没有提到，那就是由OVS分配管理的mbufs。这些内存由OVS分配管理，旨在提高datapath的运行效率，为了优化性能，显然它们也应当与QEMU及DPDK管理分配的内存位于内一个NUMA节点上。目前，这个功能由DPDK向OVS发送消息实现，DPDK会向OVS发送有关虚拟机依存的NUMA节点信息的消息，之后OVS将把mbufs使用的内存分配在正确的NUMA节点上。在DPDK向OVS发送这些消息之前，mbufs的内存始终分配在DPDK master lcore所在的NUMA节点上。
现在三部分内存都位于同一个NUMA节点了，还剩下最后一个问题：PMD轮询线程(poll mode driver threads)。
PMD轮询线程是一些比较苦逼的线程，它们日夜不停马不停蹄的轮询input ports，对收到的包进行分类，并对包执行相应的actions。在“vHost User NUMA感知”特性出现之前，所有OVS中的PMD轮询线程都住在同一个NUMA节点上，即是DPDK的master lcore所在的NUMA节点。终于，现在，社会解放了，好日子来了，PMD轮询线程和mbufs、guest memory、device tracking memory呆在同一个NUMA节点了。
下图展示了三块内存及PMD轮询线程位于同一个NUMA节点时的场景：
性能测试环境
测试环境需要一个至少有两个NUMA节点的host。上面跑着ovs+dpdk，ovs-bridge上有两个vHost User设备，我们称之分别为vhost0与vhost1。两个虚拟机跑在不同的NUMA节点上，分别称之为vm0与vm1。vhost0与vm0是一对，vhost1与vm1是一对。
下面是测试环境的规格：
Processor E5-2695 v3
Kernel 4.2.8-200
OS Fedora* 22
QEMU* 2.6.0
DPDK 16.04
OVS 914403294be2
测试环境配置过程
在安装DPDK与OVS之前，确保NUMA库已安装
sudo yum install numactl-libs sudo yum install numactl-devel
确保编译DPDK时打开了以下的配置项
CONFIG_RTE_LIBRTE_VHOST_NUMA=y
编译DPDK
链接DPDK库，编译OVS
这些都没啥可说的，毕竟装了几百回了，闭着眼睛也会做了。
配置ovs-bridge，就像上面说的那样：创建一个ovs-bridge，在下面创建两个ovs-port，类型为dpdkvhostuser或dpdkvhostuserclient。设置ovs的other_config:pmd-cpu-mask掩码时，为两个NUMA节点雨露均沾，平均分配。比如，在一个28个逻辑核心的机器上，0~13号核心在NUMA节点0上，14~17号核心在NUMA节点1上，那么如下设置就是雨露均沾：
ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=10001
# 10001是16进制，翻译成二进制是10000000000000001，即PMD轮询线程的核心亲合设置为0号核心与16号核心两个核心，其中0号核心位于NUMA节点0,1号核心位于NUMA节点1 # 这篇文章比较奇怪，只有一个cpu socket，这个cpu型号，即E5 2695 v3是14核心28线程的，按理来说应该只有一个numa节点啊。难道用一个cpu socket也能组两个numa节点？
在启动虚拟机之前，使用如下命令检查一个pmd设置
ovs-appctl dpif-netdev/pmd-rxq-show
在启动虚拟机之前，QEMU还没有分配内存，也肯定谈不上发消息给DPDK，DPDK就更谈不上发消息给OVS了，所以此时这时PMD线程将落在同一个NUMA节点上，显示如下：
pmd thread numa_id 0 core_id 0: port: dpdkvhostuser1 queue-id: 0 port: dpdkvhostuser0 queue-id: 0
然后启动虚拟机，在两个NUMA节点上分别启动vm0与vm1，下面以qemu为例，为了确保两个虚拟机分别跑在两个NUMA节点上，使用taskset命令，如下：
sudo taskset 0x2 qemu-system-x86_64 -name vm0 -cpu ... sudo taskset 0x2000 qemu-system-x86_64 -name vm1 -cpu ...
这时查看虚拟机的log，vm1会打印出如下的log：
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ADDR VHOST_CONFIG: reallocate vq from 0 to 1 node VHOST_CONFIG: reallocate dev from 0 to 1 node
出现上面这样的log就意味着DPDK的device tracking memory被从临时住所挪到了正确的NUMA节点上
另外一个验证方法是使用pmd-rxq-show工具，显示如下：
pmd thread numa_id 1 core_id 20: port: dpdkvhostuser1 queue-id: 0 pmd thread numa_id 0 core_id 0: port: dpdkvhostuser0 queue-id: 0
dpdkvhostuser1现在被一个位于NUMA节点1上的线程服务着，这也正是vm1所在的NUMA节点