本文主要对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/unbindecho 0000:04:00.3 > /sys/bus/pci/drivers/mlx5_core/unbind
-
开启OFFLOAD：
echo switchdev > /sys/class/net/eth0/compat/devlink/modeethtool -K eth0 hw-tc-offload on
开启offload后会生成，vf representor，一种vport，对于没有硬件流表无法hit的报文，通过vf rep上送ovs处理。
OVS操作步骤
-
安装ovs，测试时使用源码编译安装，版本2.11.0
modprobe openvswitchovs-ctl start //启动ovsovs-vsctl add-br ovs-sriov ovs-vsctl set Open_vSwitch . other_config:hw-offload=trueovs-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_0ovs-vsctl add-port ovs-sriov ens3f0_1ip link set dev ens3f0_0 upip 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=98ovs-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 eth0ovs-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-vm1export GUEST_MEM=8192Mexport 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/bashDOMAIN=fedora27-tap01PF=enp66s0f0VF_NUM=5TAP_IF=tap01VF_XML=vf_xmlMAC=52:54:00:00:12:53ZERO_MAC=00:00:00:00:00:00virsh domif-setlink $DOMAIN $TAP_IF up --启动virt io设备bridge fdb del $MAC dev $PF mastervirsh detach-device $DOMAIN $VF_XML --detach掉vfip link set $PF vf $VF_NUM mac $ZERO_MACvirsh migrate --live $DOMAIN qemu+ssh://$REMOTE_HOST/system ---开始迁移# Destination Hypervisor#!/bin/bashvirsh 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云计算
