译文：ovs+dpdk中的“vHost User NUMA感知”特性

　　本文描述了“vHost User NUMA感知”的概念，该特性的测试表现，以及该特性为ovs+dpdk带来的性能提升。本文的目标受众是那些希望了解ovs+dpdk底层细节的人，如果你正在使用ovs+dpdk在NUMA host上配置虚拟化平台，使用vHost User类型的port作为guest的虚拟网络配置，那么本文或许会给你一些优化性能的灵感。

 

　　注意：在本文成文之际，vHost User NUMA感知这个特性仅在OVS master分支上可用。要下载OVS master分支，请戳这里。要获取ovs+dpdk的配置步骤，请戳这里。

 

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是16进制，翻译成二进制是10000000000000001，即PMD轮询线程的核心亲合设置为0号核心与16号核心两个核心，其中0号核心位于NUMA节点0,1号核心位于NUMA节点1
# 这篇文章比较奇怪，只有一个cpu socket，这个cpu型号，即E5  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  core_id :
        port: dpdkvhostuser1    queue-id:
        port: dpdkvhostuser0    queue-id: 

　　然后启动虚拟机，在两个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  to  node
VHOST_CONFIG: reallocate dev from  to  node

　　出现上面这样的log就意味着DPDK的device tracking memory被从临时住所挪到了正确的NUMA节点上

　　另外一个验证方法是使用pmd-rxq-show工具，显示如下：

pmd thread numa_id  core_id :
        port: dpdkvhostuser1    queue-id:
pmd thread numa_id  core_id :
        port: dpdkvhostuser0    queue-id: 

　　dpdkvhostuser1现在被一个位于NUMA节点1上的线程服务着，这也正是vm1所在的NUMA节点

 

 

 

---

原文地址：

https://software.intel.com/en-us/articles/vhost-user-numa-awareness-in-open-vswitch-with-dpdk