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

服务器

浏览数:94

2019-5-17

  本文描述了“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
# 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节点       原文地址:

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

               

作者:张浮生