女主宣言

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

PS：丰富的一线技术、多元化的表现形式，尽在“360云计算”，点关注哦！

背景简介

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

涉及的技术

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给虚机使用；

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

测试要求

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开启

主机环境配置步骤

• 开启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处理。

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

VXLAN环境下测试结果

host1流表情况

内核

网卡

host2流表情况

内核

网卡

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

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

VLAN环境下测试结果

host1流表情况

内核

网卡

host2流表情况

内核

网卡

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以上

360云计算

由360云平台团队打造的技术分享公众号，内容涉及数据库、大数据、微服务、容器、AIOps、IoT等众多技术领域，通过夯实的技术积累和丰富的一线实战经验，为你带来最有料的技术分享