奇技 · 指南

本文主要对Mellanox CX-5网卡支持OVS流表加速功能进行了调研,简单介绍了配套软件的版本要求,并描述了整体测试的步骤,另外对其支持VF热迁移也进行了初步的调研,希望对有相同需求的同学有所帮助。

1

背景简介

广泛的业务层需求致使数据中心快速增长,数据流量日益激增,vSwitch会大量占用宿主机计算资源,增加运营成本,虽然可以通过cpu及irq亲和性提高转发性能,但由于性能上的瓶颈,难以满足当前快速增长的高网络带宽应用需求。因此,进一步加速vSwitch势在必行。

2

涉及的技术

1.VT-d

Intel Virtualization Technology for Direct I/O,是对IO的虚拟化技术,在io透传虚拟化中,当一个虚机直接和IO设备对话时,它提供给这个设备的地址是虚机的物理地址(GPA),那么设备拿着这个地址去发起DMA势必会失败。

难点就是DMA的操作如何直接访问宿主机的物理地址,因此,vt-d在芯片组里引入了DMA重映射的硬件,就是IOMMU,负责对DMA的地址做转换(IO页表),也存在IOTLB,vt-d的功能主要包括,IO设备分配、DMA重映射、中断重映射。

2.SR-IOV

sriov技术就是为了解决网卡透传到虚机后,网卡不足的问题,支持水平扩展网卡,一个io设备最多支持256个VF;

PF用来配置和管理sriov,拥有所有的pcie资源;

VF是精简的pcie功能,由PF创建和销毁,拥有独立的pci配置空间,收发队列,中断等,宿主机可以分配一个或者多个VF给虚机使用;

把一个网卡透传到虚机中,其收发流程与宿主机上直接使用一样,主要不同在于地址访问多做了一次地址转换。

3

测试要求

1)开启vf前,安装firmware-tools工具,安装OFED驱动,可去官网下载

https://cn.mellanox.com/products/adapter-software/firmware-tools

https://cn.mellanox.com/products/infiniband-drivers/linux/mlnx_ofed

2)版本要求:

  * Linux Kernel >= 4.13-rc5 (Upstream Kernel)
    >= 3.10.0-860 (RedHat Based Distributions)

 * Mellanox NICs FW
    FW ConnectX-5: >= 16.21.0338

 * iproute >= 4.11

 * upstream openvswitch >= 2.8

 * openstack >= Pike version

 * SR-IOV enabled

3)开启VT-d及iommu

vt-d在bios开启,iommu在cmdline开启

4

主机环境配置步骤
  • 开启sriov:

echo 0 > /sys/class/net/eth0/device/sriov_numvfs 
echo 2 > /sys/class/net/eth0/device/sriov_numvfs 
  • 设置vfmac:

# ip link set eth0 vf 0 mac e4:11:22:33:44:52
# ip link set eth0 vf 1 mac e4:11:22:33:44:53
  • 解绑VF:

echo 0000:04:00.2 > /sys/bus/pci/drivers/mlx5_core/unbind
echo 0000:04:00.3 > /sys/bus/pci/drivers/mlx5_core/unbind
  • 开启OFFLOAD:

echo switchdev > /sys/class/net/eth0/compat/devlink/mode
ethtool -K eth0 hw-tc-offload on

开启offload后会生成,vf representor,一种vport,对于没有硬件流表无法hit的报文,通过vf rep上送ovs处理。

5

OVS操作步骤
  • 安装ovs,测试时使用源码编译安装,版本2.11.0

modprobe openvswitch
ovs-ctl start //启动ovs
ovs-vsctl add-br ovs-sriov 
ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
ovs-vsctl set Open_vSwitch . other_config:tc-policy=skip_sw    ----默认ovs内核及kernel都会下流表,skip是只下硬件
restart ovs
  • 将两个vf rep添加到 ovs 桥

ovs-vsctl add-port ovs-sriov ens3f0_0
ovs-vsctl add-port ovs-sriov ens3f0_1
ip link set dev ens3f0_0 up
ip link set dev ens3f0_1 up
  • 添加vxlan port //如果为vlan环境,则添加vlan tag

//vxlan环境
ovs-vsctl add-port ovs-sriov vxlan0 -- set interface vxlan0 type=vxlan options:local_ip=1.1.1.1 options:remote_ip=1.1.1.2 options:key=98
ovs-vsctl add-port ovs-sriov vxlan0 -- set interface vxlan0 type=vxlan options:local_ip=1.1.1.2 options:remote_ip=1.1.1.1 options:key=98


//vlan环境
ovs-vsctl add-port ovs-sriov eth0
ovs-vsctl add-port ovs-sriov enp26s0f0_0 tag=100
  • 启动虚机前,加载vfio及vfio-pci驱动

modprobe vfio 
modprobe vfio-pci
  • 绑定驱动到vfio:

lspci -ns 0000:1a:00.2    #vf的pci地址
echo 15b3 1018 > /sys/bus/pci/drivers/vfio-pci/new_id
  • 环境变量设置:

export VM_NAME=vhost-vm1
export GUEST_MEM=8192M
export QCOW2_IMAGE=/home/zhailiansen/qemu_image.qcow2
  • 设置虚机的cpu与网卡在同一个socket:

taskset 0xF0 /usr/local/bin/qemu-system-x86_64 -name $VM_NAME -smp 4 -cpu host -enable-kvm \
-m $GUEST_MEM -drive file=$QCOW2_IMAGE --nographic -snapshot \
-device vfio-pci,host=0000:1a:00.2

6

VXLAN环境下测试结果

HOST1流表情况

内核

网卡

HOST2流表情况

内核

网卡

因为报文从硬件直接转发,粗略计算ovs时延,15us,环境纯净,只有ping 包,实际还包含虚机将报文扔给vf时的时间开销,比如DMA时虚机内存地址到宿主机内存地址的转换,以及两台host在交换机查表转发的延时,网卡硬件的查表转发是相当快的,15us不足以体现其性能。

相同环境下对比virtio的延时,拓扑如下图,ovs延时达到113us,vm存在一定流量的情况下,延时上升到几百us,而硬件的延时几乎未有提升。

7

VLAN环境下测试结果

HOST1流表情况

内核

网卡


HOST2流表情况

内核

网卡

8

VF热迁移功能调研

综合现在的软件版本,及环境表现,还不能够支持sriov 的虚机热迁移,下边分析下sriov 热迁移的原理:

1、热迁移使用内核的net_failover设备。

2、net_failover原理

net_failover driver会创建一个net_failover设备,一个failover master netdev去管理一个primary 和 standby slave netdev,primary和standby需提前注册到net_failover。相当于一个failover设备管理两个slave设备。图中vf是 primary 设备, virtio是standby设备,他们具有相同的mac地址,用户通过failover设备访问外网,failover选择primary netdev传输流量。当vf unplug时,数据路径,failover到virtio路线,用于热迁移。qemu需支持 VIRTIO_NET_F_STANDBY 这个virtio_net device的标志位,以便 hypervisor 可以感知到,该virtio设备作为一个vf设备的standby设备。热迁移完成时,需attach一个vf到虚机,这个操作需要libvirt支持,之后vm数据路径切换到vf。

libvit为例,看一下迁移过程:

1、网卡xml配置

# cat vf_xml
<interface type='hostdev' managed='yes'>
  <mac address='52:54:00:00:12:53'/>
  <source>
    <address type='pci' domain='0x0000' bus='0x42' slot='0x02' function='0x5'/>
  </source>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
</interface>

2. 迁移步骤

# Source Hypervisor
#!/bin/bash
DOMAIN=fedora27-tap01
PF=enp66s0f0
VF_NUM=5
TAP_IF=tap01
VF_XML=vf_xml
MAC=52:54:00:00:12:53
ZERO_MAC=00:00:00:00:00:00
virsh domif-setlink $DOMAIN $TAP_IF up     --启动virt io设备
bridge fdb del $MAC dev $PF master
virsh detach-device $DOMAIN $VF_XML        --detach掉vf
ip link set $PF vf $VF_NUM mac $ZERO_MAC
virsh migrate --live $DOMAIN qemu+ssh://$REMOTE_HOST/system  ---开始迁移
# Destination Hypervisor
#!/bin/bash
virsh attach-device $DOMAIN $VF_XML                -----attach vf 发设备到虚机
virsh domif-setlink $DOMAIN $TAP_IF down           -----down掉 virtio设备

在目的机器怎么选择VF, 通过在计算节点配置文件,配置 passthrough_whitelist,这里是VF 的列表。

由于目前停留在openstack s版本,一些功能还需要开发支持,以及各个组件版本的配合,如下:

nova要做的事,

1、nova需要组织这两种设备到xml中,传给libvirt启动虚机
2、libvirt需支持参数的解析,传给qemu
3、qemu需支持failover相关功能
4、内核需要支持创建failover设备
5、迁移时需支持plug 及 unplug pci 设备。

neutron:
1、neutron 需要ovs支持添加 vf rep 口到ovs桥,为offload miss添加上送通道。
2、目前 sriov agent只支持vlan,需开发支持vxlan功能,联动ovs 下发流表。目前看到openstack T版已有支持。
3、哪些能下,哪些不能下

  1)支持,vxlan、vlan卸载
  2)不支持路由规则
  3)不支持安全组
  Mellanox CX-5网卡在基于SRIOV加速的场景下,不支持ct_state,导致涉及到ct操作带有ct_state匹配字段的流表均不能通过TC下发到网卡中,这时仍然需要在内核态完成这些操作

  支持这些功能的卸载,需要先转换成流表,这就需要类似ovn的功能加持,这些都需要实际开发中去实现。

各个组件版本要求:
kernel要求:4.18–4.20, 5.0–5.11, 5.12-rc+HEAD(宿主机及虚机内核) 
qemu:stable-4.2   
libvirt:5.3以上     

END

查看历史文章

Kubevirt在360的探索之路(K8S接管虚拟化)
如何提高大规模正则匹配的效能
360Stack裸金属服务器部署实践

360技术公众号

技术干货|一手资讯|精彩活动

扫码关注我们

Logo

华为开发者空间,是为全球开发者打造的专属开发空间,汇聚了华为优质开发资源及工具,致力于让每一位开发者拥有一台云主机,基于华为根生态开发、创新。

更多推荐