伴隨著電商等用戶在雙11、秒殺之類業(yè)務(wù)高峰期流量的迅猛增長，對虛擬機(jī)網(wǎng)絡(luò)性能提升的需求日益迫切，25G網(wǎng)絡(luò)逐漸成為一種標(biāo)配。為了解決傳統(tǒng)純軟件Virtual Switch方案帶來的性能瓶頸，我們在調(diào)研了業(yè)界主流的智能網(wǎng)卡方案之后，最終決定采用基于OpenvSwitch的開源方案，并成功在公有云落地應(yīng)用。

[[250725]]

相較于傳統(tǒng)方案，新的智能網(wǎng)卡方案在整個switch的轉(zhuǎn)發(fā)上性能為小包24Mpps，單VF的接收性能達(dá)15Mpps，網(wǎng)卡整體性能提升10倍以上。應(yīng)用于云主機(jī)后，可將其網(wǎng)絡(luò)能力提升至少4倍，時延降低3倍，有效解決電商等業(yè)務(wù)高峰期的穩(wěn)定性問題。本文將詳細(xì)講講新方案從選型到落地過程中遇到的坑及解決之道，希望能給人以借鑒與啟發(fā)。

業(yè)界主流的智能網(wǎng)卡方案對比

傳統(tǒng)的軟件Virtual Switch的性能瓶頸，在于其從物理網(wǎng)卡接收報(bào)文后，是按照轉(zhuǎn)發(fā)邏輯發(fā)送給vhost線程，vhost再傳遞給虛擬機(jī)的方式執(zhí)行，如此一來，vhost的處理能力就成為了影響虛擬機(jī)網(wǎng)絡(luò)性能的關(guān)鍵。

于是，在宿主機(jī)上通過25G SmartNIC對網(wǎng)絡(luò)流量進(jìn)行卸載成為業(yè)界公認(rèn)的主流方向?，F(xiàn)階段，智能網(wǎng)卡的實(shí)現(xiàn)百花齊放，例如：AWS采用基于通用ARM的眾核方案、Azure采用基于FPGA的方案、華為云采用基于專用網(wǎng)絡(luò)處理器(NP)的方案、阿里云采用基于可編程ASIC芯片的方案。就目前來看各個方案各有優(yōu)劣，并沒有特別突出一統(tǒng)天下的方案。

基于通用ARM、MIPS的眾核方案，簡單將原來跑在宿主機(jī)上的vSwitch移植到網(wǎng)卡上，既可以支持Linux Kernel也可以支持DPDK，從而達(dá)到釋放宿主機(jī)計(jì)算資源的目的。而其他基于FPGA、NP和可編程ASIC的方案，大多在網(wǎng)卡上維護(hù)一個快速轉(zhuǎn)發(fā)路徑(Fast Path)，當(dāng)收到報(bào)文后，首先檢查是否在Fast Path已經(jīng)緩存了該類報(bào)文的處理規(guī)則，如果找到，則直接按照規(guī)則執(zhí)行動作，否則就轉(zhuǎn)發(fā)到Slow Path去處理。而這個Slow Path可以是DPDK，也可以是Linux Kernel。

因此，F(xiàn)ast Path最重要的是看是否支持足夠多的Action，以及自定義Action的可擴(kuò)展性。Slow Path和Fast Path通信除了各廠商的私有接口外，也有標(biāo)準(zhǔn)的TC Offload接口和DPDK提供的RTE Flows接口。

不過，F(xiàn)PGA的功耗和成本較高，研發(fā)周期長且不能快速地落地，從硬件到軟件都需要投入大量的資源。而其他基于第三方網(wǎng)卡廠家的軟件定制化方案，對于網(wǎng)卡軟件的穩(wěn)定性嚴(yán)重依賴于第三方廠商, 遇到問題時不能快速的定位排障。

我們的選擇

在業(yè)界沒有非常完美的實(shí)現(xiàn)方案下，我們開始將目光轉(zhuǎn)向開源技術(shù)，由于OpenvSwitch本身支持基于Linux Tc Flower Offload卸載接口, 對現(xiàn)有控制管理面影響小，并且能夠快速應(yīng)用落地開發(fā)給用戶使用。因此，我們選擇了基于Tc Flower Offload的OpenvSwitch開源方案。

報(bào)文處理可以被看做是通過一系列順序操作將一個報(bào)文從接收發(fā)送到最終的目的地，最典型處理的是發(fā)送或者丟棄。這一系列操作通常是連續(xù)的match然后執(zhí)行action。Linux kernel TC子系統(tǒng)的Tc Flower可以將報(bào)文基于流進(jìn)行控制轉(zhuǎn)發(fā)，而流通常是基于報(bào)文常見域來分類，這些域組成了名叫flow key的match項(xiàng)，flow key包括了報(bào)文常見域和可選的隧道信息，TC actions對報(bào)文執(zhí)行丟棄、修改、發(fā)送等操作。

這個方式類似于OpenvSwitch的分類方式。 通過Tc Flower分類器的offload對于flow-based的系統(tǒng)提供強(qiáng)有力的方法來增加吞吐量并減少CPU利用率。

基于OpenvSwitch卸載的智能網(wǎng)卡落地實(shí)踐

方案選定之后，我們開始在原有架構(gòu)上進(jìn)行落地實(shí)踐，這個過程并非一帆風(fēng)順，在具體落地的過程中，我們也遇到了幾個方面的問題：

1. 虛擬機(jī)的遷移

落地之初，首先要進(jìn)行虛擬機(jī)的遷移。因?yàn)楦鱾€廠商的SmartNIC都是基于VF passthrough的方案，而VF的不可遷移性為虛擬機(jī)遷移帶來了困難。在業(yè)界，Azure主要通過bonding VF和virtio-net device的方案解決這一問題，但是這種方法需要用戶在一定層面上的介入，帶來了虛擬機(jī)鏡像管理的問題。

通過調(diào)研upstream(https://patchwork.ozlabs.org/cover/920005/ )“Enable virtio_net to act as a standby for a passthrough device” 方案，我們發(fā)現(xiàn)此環(huán)境下，用戶不需要手工設(shè)置bonding操作或者制作特定的鏡像，可以完美的解決用戶介入的問題。最終，我們采用了 VF+standby virtio-net的方式進(jìn)行虛擬機(jī)的遷移。具體遷移過程為：

l 創(chuàng)建虛擬機(jī)自帶virtio-net網(wǎng)卡，隨后在Host上選擇一個VF 作為一個hostdev的網(wǎng)卡，設(shè)置和virtio-net網(wǎng)卡一樣的MAC地址，attach到虛擬機(jī)里面，這樣虛擬機(jī)就會對virtio-net和VF網(wǎng)卡自動形成類似bonding的功能，此時，在Host上對于虛擬機(jī)就有兩個網(wǎng)絡(luò)Data Plane;

l virtio-net backend的tap device在虛擬機(jī)啟動時自動加入到host的OpenvSwitch bridge上，當(dāng)虛擬機(jī)網(wǎng)卡進(jìn)行切換的時候datapath也需要進(jìn)行切換。VF attach到虛擬機(jī)后，在OpenvSwitch bridge上將VF_repr置換掉tap device;

2. VXLAN encap/decap不能offload

接下來需要做SmartNIC端的適配。以Mellanox CX5網(wǎng)卡為例，軟件環(huán)境包括OpenvSwitch-2.10.0、ukernel-4.14和MLNX_OFED-4.4-1.0.0.0。由于mlx5_core driver最新版本并不支持Ethernet over GRE tunnel offload，所以我們先通過VXLAN進(jìn)行了測試。

如下圖，eth2 是PF, mlx_0是VF0的representor，通過以下命令進(jìn)行初始化。首先，開啟一個VF設(shè)備，將VF設(shè)備在driver mlx5_core上解綁，設(shè)置PF設(shè)備的IP地址，設(shè)置PF網(wǎng)卡相關(guān)switched模式，開啟PF網(wǎng)卡encap功能。

OpenvSwitch 配置如下：虛擬機(jī)VF利用representor mlx_0連接到 br0，通過vxlan0 發(fā)送給對端。VXLAN隧道本地地址為172.168.152.75，對端地址為172.168.152.208。

Encap/decap報(bào)文都能有效收發(fā)，但是并沒有offload到網(wǎng)卡上

首先發(fā)現(xiàn)dmesg顯示錯誤

查詢原因后發(fā)現(xiàn)OpenvSwitch在創(chuàng)建vxlan device時，并沒有將vxlan dport信息注冊進(jìn)網(wǎng)卡。OpenvSwitch通常是通過 vxlan device的netdev_ops->ndo_add_vxlan_port接口完成這一功能，但是在較新的內(nèi)核比如ukernel-4.14中是通過netdev_ops->ndo_udp_tunnel_add接口完成的。

后來我們給OpenvSwitch 提交patch “datapath: support upstream ndo_udp_tunnel_add in net_device_ops”https://patchwork.ozlabs.org/patch/953417/ 來解決這一問題。

3. Decap報(bào)文不能offload

解決上述問題后，egress方向的encap報(bào)文雖然可以有效的offload，但是ingress decap報(bào)文卻依然不可以。

case2的vxlan decap打印是在mlx_0 VF上，因此我們推測decap規(guī)則可能也下發(fā)到了VF port上。由于tc規(guī)則設(shè)置于vxlan_sys的虛擬device上，因而很可能是在尋找設(shè)置的物理網(wǎng)卡上出現(xiàn)了問題。

通過代碼分析，可以看到虛擬device的設(shè)置物理網(wǎng)卡是通過action device找到的，即mlx_0 VF，而OpenvSwitch下發(fā)給mlx_0 VF的tc_flower帶著egress_dev為true的標(biāo)志，由此推斷，TC規(guī)則是設(shè)置在VF對應(yīng)的PF上。

沿著此推斷，我們查看了mlx5 driver的代碼backports/0060-BACKPORT-drivers-net-ethernet-mellanox-mlx5-core-en_.patch

發(fā)現(xiàn)ukernel-4.14可以支持cls_flower->egress_dev flag，但并不支持HAVE_TC_TO_NETDEV_EGRESS_DEV。因此，我們斷定mlx5_core driver在內(nèi)核兼容性的判斷上出現(xiàn)問題。隨后，我們提交了相應(yīng)的patch給Mellanox解決此問題。

4. Backend tap device encap報(bào)文被丟棄

在做live migration時需要用到backend tap sdevice，OpenvSwitch在發(fā)送報(bào)文時將tc規(guī)則設(shè)置到了tap device上，依靠tc的in_sw方式進(jìn)行tunnel_key set然后轉(zhuǎn)發(fā)給gre_sys device進(jìn)行發(fā)送， 但是gre_sys device直接將報(bào)文丟棄，這讓我們非常詫異。

分析其原因，我們發(fā)現(xiàn)，在tc offload的in_sw情況下，報(bào)文會繞過 OpenvSwitch的轉(zhuǎn)發(fā)邏輯直接通過gre_sys device進(jìn)行發(fā)送。而我們使用的是OpenvSwitch-2.10.0所帶的內(nèi)核模塊代碼， 內(nèi)核模塊兼容性編譯時判斷ukernel-4.14并不支持USE_UPSTREAM_TUNNEL，所以，gre_sys device并不是內(nèi)核自帶的gre設(shè)備，而是OpenvSwitch自己創(chuàng)建的一種不具備nodo_start_xmit函數(shù)的設(shè)備，OpenvSwitch內(nèi)核態(tài)gre tunnel的轉(zhuǎn)發(fā)并不通過gre_sys device真正做發(fā)送。

雖然ukernel-4.14不支持USE_UPSTREAM_TUNNEL，但對于內(nèi)核自帶的gre device是能支持通過ip_tunnel_key進(jìn)行nodo_start_xmit發(fā)送的，因而對于內(nèi)核自帶的gre device來說，USE_UPSTREAM_TUNNEL的標(biāo)志是有效的。

由此，OpenvSwitch可以通過acinclude.m4文件去判斷

由于OpenvSwitch判斷這個功能根據(jù)gre以及erspan來決定的，但ukernel-4.14對于erspan來說，USE_UPSTREAM_TUNNEL的標(biāo)志是無效的。

之后，我們引入上游https://patchwork.ozlabs.org/cover/848329/ patch系列“ERSPAN version 2 (type III) support”，使OpenvSwitch感知內(nèi)核支持USE_UPSTREAM_TUNNEL 來解決gre_sys device drop報(bào)文的問題。

5. Ethernet over gre tunnel不能offload

打入Mellanox提供了基于ethernet over gre的patch后，我們又發(fā)現(xiàn)ingress的decap方向不能做offload。

這是由于在gre_sys device上并沒有生成tc ingress qdisc，OpenvSwitch 通過vport的get_ifinex獲取device的ifindex設(shè)置tc 規(guī)則，而gre tunnel type的vport 并沒有enable get_ifindex功能。

我們查找了upstream的OpenvSwitch，并通過patch“netdev-vport: Make gre netdev type to use TC rules”解決這個問題。

此外，egress encap offload的報(bào)文也不能被對方接收，通過抓包發(fā)現(xiàn)gre header里面帶了csum field，但是OpenvSwitch上的gre tunnel并沒有設(shè)置csum options。

研究代碼cls_tunne_key的set action里默認(rèn)是帶csum field的， 必須通過顯示的設(shè)置TCA_TUNNEL_KEY_NO_CSUM才會關(guān)閉csum filed。而OpenvSwicth-2.10.0沒有做這方面的適配。

我們查找了upstream的OpenvSwitch，并最終通過patch “netdev-tc-offloads: TC csum option is not matched with tunnel configuration”解決了這一問題。

綜上，我們詳細(xì)介紹了UCloud 25G SmartNIC的選型方案，以及在實(shí)踐的過程中遇到的各種技術(shù)問題及其解決方案，通過對ukernel、OpenvSwitch、mlx5_core driver的功能補(bǔ)全和bugfix，最后將這一開源方案成功落地應(yīng)用。

性能對比

落地應(yīng)用后，我們基于OpenvSwitch卸載的高性能25G智能網(wǎng)卡方案下，從vSwitch性能、 虛擬網(wǎng)卡性能等維度進(jìn)行了系列性能測試。可以看到，

單VF的接收性能可達(dá)15Mpps：

整個vSwitch的轉(zhuǎn)發(fā)性能為小包24Mpps：

而一般傳統(tǒng)純軟件環(huán)境下，vSwitch的轉(zhuǎn)發(fā)性能為2Mpps，虛擬網(wǎng)卡的接收性能僅1.5Mpps左右。相較于原方案，網(wǎng)卡整體性能提升了10倍以上。

應(yīng)用在云主機(jī)時，同樣8核配置的主機(jī)，以收向UDP小包(1 Byte)場景為例，新方案的PPS值可達(dá)469w，而原值為108w。

后續(xù)計(jì)劃

目前，該方案已經(jīng)成功應(yīng)用于公有云上，將作為網(wǎng)絡(luò)增強(qiáng)2.0云主機(jī)推出，使云主機(jī)的網(wǎng)絡(luò)能力提升到目前網(wǎng)絡(luò)增強(qiáng)1.0版本的4倍以上。后續(xù)我們計(jì)劃將該方案移植到Bare Metal物理云主機(jī)產(chǎn)品上，讓公有云和物理云主機(jī)在功能和拓?fù)渖弦恢?，并研究有狀態(tài)的Firewall/NAT的Offload。