基於智能網卡（Smart Nic）的Open vSwitch卸載方案簡介

 

 

一、Smart Nic簡介

1.1 Smart Nic產生的背景

 

 

 

目前，以Open vSwitch（OVS）為代表的虛擬交換機（vSwitch）以其靈活而豐富的功能支持（如OpenFlow、QOS、VLAN/VXLAN encap/decap）被業界廣泛接受，大量應用於雲計算多租戶場景以及容器場景中。廣泛的業務層需求致使數據中心快速增長，數據流量日益激增，vSwitch的收發包瓶頸也日益凸顯出來，雖然可以通過軟件加速套件（例如dpdk），在一定程度上增強轉發性能，但是仍存在以下幾個問題：

 

首先，vSwitch會大量占用宿主機計算資源，尤其是當吞吐增大時，為保證轉發質量，vSwitch通常會綁定多個CPU核，這會額外占用大量寶貴的CPU資源，無形之中增加了企業運行成本和能源消耗，這些CPU資源原本可以在其它業務和應用中進行更合理的利用。

 

其次，雖然可以通過CPU Affinity以及IRQ Affinity等優化手段提高轉發性能，但是vSwitch依然面臨着性能上的瓶頸，難以滿足當前快速增長的高網絡帶寬應用需求。因此，進一步加速vSwitch勢在必行。

 

最后，業務/應用需求和軟件實現上的矛盾，促成了Smart Nic的出現，以Smart Nic為代表的硬件卸載（Hardware Offload）方案被提出並得以廣泛推進。

 

Smart Nic技術誕生的初衷是以比普通CPU低得多的成本來實現對各種虛擬化功能的支持，如sriov，overlay encap/decap，以及部分vSwitch處理邏輯的offload。而且，Hardware Acceleration方案具有天生的處理速度快、性能穩定等優勢。除此之外，網卡作為數據流進出的首道關卡，還可以實現監控、嗅探、以避免網絡攻擊、實現安全隔離的作用。

 

1.2 Smart Nic和Normal Nic區別

 

相比於Normal Nic，Smart Nic在很多方面做了改進，例如:

 

1. Hardware Offload/Acceleration功能

 

• 區別於Normal Nic，Smart Nic不僅負責L2轉發，通過增加額外的處理邏輯還可以實現部分vSwitch的功能。基於Hardware Offload，能夠offload部分網絡流量（例如基於Tc Flower Offload功能），以及支持對網絡數據包header的處理（例如Push/Pop VLAN Tag、VXLAN Encap/Decap等），減小CPU負載，提高網絡吞吐；

   

• Connection Tracking Offload可以實現L3/L4 Firewall功能；

   

• Header Re-write Offload功能，能夠對packet header進行set/copy/add操作，可以實現routing、nat等功能；

 

2. 可編程功能

Smart Nic具備可編程能力，除了實現高性能網絡轉發以后，還可以實現諸如流表規則匹配，封包過濾，NVMe等功能。表1列出了Smart Nic部分功能的使用場景，以及控制平面/數據平面的功能分工^[2]。

 

表1. Smart Nic部分功能使用場景

 

1.3 Smart Nic架構

 

目前幾種主流的Smart Nic架構各不相同，大致可以分為ASIC Based、FPGA Based、以及SOC Based三種類型。下圖1從性能價格比、操作難易程度、靈活性等幾個方面對這三種硬件架構做了簡單比較^[1]。從圖中可以看出，ASIC架構Smart Nic（例如mallanox connectX-5系列）成本低廉且性能優異，這種類型的Smart Nic一般都有可編程接口，但由於處理邏輯在ASIC上固化，控制的靈活空間會比較小；與之相比，基於FPGA的Smart Nic（例如napath NT100E3-1-PTP系列）靈活性則更高，但是成本略高並且編程難度較大；SOC架構（即含有專用CPU，例如mellanox BlueField系列）提供了性能和可操控性的平衡，使用這種架構的一般是各大廠商的自研網卡。

 

目前，在解決傳統的vSwitch性能瓶頸方面，業界還沒有一個非常完美的Smart Nic方案，各個方案的實現也是各有千秋，並沒有形成一個統一的方案。比如，AWS采用基於通用ARM的方案、Azure采用基於FPGA的方案、華為雲采用基於專用網絡處理器（NP）的方案、阿里雲采用基於可編程ASIC芯片的方案等。

 

圖1. Smart Nic不同架構對比

二、基於Smart Nic的OVS卸載方案

2.1 virtio純軟轉發的方案

 

阿里雲曾經提出過一個virtio純軟轉發的方案。阿里雲針對自身業務自主開發的AVS項目（和OVS有類似功能）在使用過程中，遇到了諸如AVS占用主機資源過多、業務需求導致的性能瓶頸等問題，也因此催生了Smart Nic項目，方案如下圖2所示。結合了SRIOV和virtio的優劣，設計了一套基於純軟轉發的方案^[3,4]。

 

圖2所示是阿里雲的Smart Nic設計框架，卡上有一個標准的網卡ASIC和片上系統，片上系統自帶內存和CPU，AVS模塊整體offload到Smart Nic中。將快速路徑（fast-path）和慢速路徑（slow-path）進行分離，fast-path offload到ASIC中，AVS自身只負責slow-path包轉發。

 

同時，阿里雲結合自己的業務需求，在上層開發了一個基於DPDK的軟件轉發程序，AVS在網卡完成所有的策略、邏輯、路由、多隊列等功能，將SRIOV的VF設備和virtio-net驅動接口進行一一映射，DPDK軟件轉發程序只需要完成VF和virtio-net的接口轉換和報文傳遞。

 

該方案具有性能好、不占用主機資源、接口通用以及熱遷移方便等優點，已經在阿里雲上有了廣泛的應用。

 

圖2. 阿里雲Smart Nic方案

 

2.2 基於代表口映射的方案

采用基於代表口映射方案的是Mellanox廠商，其生產的mellanox connectX系列網卡以高帶寬、低延時、高性價比等著稱。Mellanox提供的Smart Nic方案^[5]，如下圖3 （a）所示，采用了embeded switch（eSwitch），將OVS的數據面offload到網卡中，控制面保持不變，以提供簡便靈活的控制。

 

從圖3（b）所示的數據包傳輸路徑可知，普通OVS在做包轉發處理時，首先在kernel space進行查表，如果lookup miss，則會發送netlink upcall信息到user space進行后續的查找（紫色線所示）；user space查表，lookup hit以后，會將查表命中的flow table entry下發到kernel space進行緩存，以便后續報文在kernel space能直接hit，從而完成直接轉發（黃色線所示），采用這種flow cache技術，能夠減少頻繁的內核態和用戶態進程交互產生的性能開銷，提高轉發性能，進而提高吞吐；采用eSwitch這種ovs offload方案后，能夠進一步優化轉發性能，進一步縮短數據包的傳輸路徑，當流緩存到網卡后，后續報文的解析、流表查找和轉發等則會直接在網卡內部完成。值得注意的是，Mellanox的這種方案實現的是ovs的fastpath offload，而非full datapath offload。

 

圖3. Mellanox Smart Nic方案

（a）基於eSwitch offload方案（b）OVS轉發邏輯示意圖

 

Mellanox Smart Nic提供了基於SRIOV的加速方案以及基於virtio的DPDK加速方案，后者現在尚未發布，預計2019年年末發布。圖4是Mellanox 基於SRIOV的加速方案，可以看出，在SRIOV環境下，vf設備直接透傳給vm使用，同時，vf設備建立起和rep代表口的一一映射關系（由Smart Nic實現完成），宿主機OVS需要配置hw-offload=true，打開hardware offload功能，以便OVS能夠將內部流表通過TC下發到網卡內部的eSwitch，配置完成后，可以使用和普通OVS場景一樣的方式，添加網橋，添加端口（rep代表口）到網橋上，對應的流表會下發到網卡內部，這樣虛機之間的流量通信就可以在網卡內部完成，而不需要經過vSwitch的處理邏輯，減小了系統資源占用，同時相比傳統的SRIOV場景，增添了更為豐富的控制功能。

 

圖4. Mellanox SRIOV加速方案

 

三、基於Mellanox ConnectX-5 Smart Nic實踐

3.1前置條件

 

• Linux Kernel >= 4.13

• Open vSwitch >= 2.8

• Iproute >= 4.12

• Mellanox ConnectX-5 Smart Nic

• Mellanox ConnectX-5 FirmWare >= 16.21.0338

• Mellanox Driver（based on the kernel version）

 

3.2 創建VF

 

• 使能SRIOV && VT-d，grub配置文添加內核參數intel_iommu=on；

• 創建VF口（假設網卡名為enp6s0f0）；

#  echo 0 > /sys/class/net/enp6s0f0/device/sriov_numvfs
#  echo 2 > /sys/class/net/ enp6s0f0/device/sriov_numvfs

 

• 驗證檢查創建的VF口（假設生成的VF口分別為enp6s0f0_0和enp6s0f0_1）；

#  cat /sys/class/net/ enp6s0f0/device/sriov_totalvfs
#  ip link show enp6s0f0
// 如果網卡或者創建VF口狀態為down，則需要設置為up狀態
#  ip link set dev enp6s0f0 up
#  ip link set dev enp6s0f0_0 up
#  ip link set dev enp6s0f0_1 up

3.3 配置Open vSwitch

 

• 將PF設備的eswitch模式從legacy更改為switchdev（假設pci號為04:00.0）；

#  echo switchdev > /sys/class/net/enp6s0f0/compat/devlink/mode

 

或者使用devlink工具，如下

#  devlink dev switch set pci/0000:04:00.0 mode switchdev

• Unbind VF（假設pci號分別為04:00.1，04:00.2）；

#  echo 0000:04:00.1 > /sys/bus/pci/drivers/mlx5_core/unbind
#  echo 0000:04:00.2 > /sys/bus/pci/drivers/mlx5_core/unbind

• 使能網卡的Hardware Offload功能；

#  ethtool -K enp6s0f0 hw-tc-offload on

• 使能Open vSwitch的Hardware Offload功能；

#  systemctl start openvswitch
#  ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
#  systemctl restart openvswitch

• 配置Open vSwitch；

#  ovs-vsctl add-br ovs-sriov
#  ovs-vsctl add-port ovs-sriov enp6s0f0
#  ovs-vsctl add-port ovs-sriov enp6s0f0_0
#  ovs-vsctl add-port ovs-sriov enp6s0f0_1
#  ovs-dpctl show

• Openstack環境下創建port時，注意需要傳入capability:switchdev參數；

#  openstack port create --network net_1     --vnic-tpye=direct --binding-profile '{"capabilities":{"switchdev"}}'  sriov_port1
#  openstack port create --network net_1     --vnic-tpye=direct --binding-profile '{"capabilities":{"switchdev"}}'  sriov_port2

• 創建vm1和vm2，分別選定sriov_port1和sriov_port2，然后ping；

 vm1# ping vm2

• 在rep口tcpdump抓取vm之間的icmp報文，如圖5所示，只能抓到第一筆ping包以及arp request/reply包（vm1持續ping vm2，后續ping包和arp包都會經過網卡轉發，rep口就抓不到包了），這說明后續虛機之間的流量offload到了網卡，在網卡中實現了轉發，而不再經由OVS進行轉發；

 

圖5. 同節點虛機互ping時Representor口抓包結果

 

• 查看流表轉發規則：可以看到已經offload到網卡上的流表；

#  ovs-dpctl dump-flows type=offloaded

 

可以看到類似如下圖6所示的輸出結果：

圖6. Offload到網卡上的流表示例

 

 

3.4 測試結果

 

下圖是采用iperf跨節點打流測試獲取的實驗數據，分別對如下三種實驗場景進行了測試：

 

• 傳統SRIOV場景（即下圖的legacy sriov），對應使用的是傳統10G網卡；

• 開啟Hardware Offload（fastpath offload）功能的Mellanox CX-5 25G網卡實驗場景（為了進行對比測試，將interface speed配置為10G），其中又分為兩類:

 

1.  沒有安全組的hardware offload場景（即下圖的fastpath offload without sg），對應是傳統sriov場景；

    

2. 包含安全組的hardware offload場景（即下圖的fastpath offload with sg），帶有安全組的這種場景，包含了一些控制流，需要使用ovs的conntrack功能。

圖6. 實驗對比圖

 

通過上圖6的實驗對比圖可以看到，不帶sg的fastpath offload場景下，網絡吞吐為9.18Gbps，和傳統的SRIOV場景（吞吐為9.32Gbps）相比，基本持平，這是因為Mellanox的這種方案是基於SRIOV加速的，因此轉發速率逼近傳統SRIOV場景下的性能，並沒有較大的性能損耗；而帶有sg的fastpath offload場景下，網絡吞吐只達到7.5Gbps，性能出現了較大的下降，是因為Mellanox CX-5網卡在基於SRIOV加速的場景下，不支持ct_state，導致涉及到ct操作帶有ct_state匹配字段的流表均不能通過TC下發到網卡中，這時仍然需要在內核態完成這些操作，也因此出現了性能較大損耗的問題。

 

傳統的SRIOV場景，虛機流量經網卡轉發，雖然傳輸路徑短，轉發性能很高，但是流量控制基本上脫離主機，無法進行控制；Mellanox CX-5網卡基於SRIOV加速流量轉發，可以通過conntrack實現流量的控制，進而實現安全組功能，但是目前由於功能上的不完善，導致在開啟安全組時，網絡轉發性能降低，網絡吞吐下降。

 

由此也可以看出，Mellanox Smart Nic的Hardware Offload功能雖然很強大，但是仍然有一些不完善的地方，后續仍需要持續開展軟硬件協同，以及進一步的對接和優化工作。

 

四、Smart Nic應用前景

當前，隨着眾多業務和應用上需求導致的數據流量激增，對虛擬網絡性能的提高變得日益迫切。傳統的一些虛擬交換技術難以滿足當前快速增長的高網絡帶寬應用需求，Smart Nic能夠實現眾多的Hardware Offload功能，為CPU“減負”，釋放寶貴的CPU資源，大大提高網絡和應用性能，對網絡虛擬化應用的性能有很大影響。

 

目前業內主流廠商都已經進行了Smart Nic的相關研發，有些Smart Nic方案也已經應用到了實際項目中。但是，各個廠商使用的Smart Nic 架構和方案不盡相同，Smart Nic方案目前也比較多，各個方案的實現各有利弊，並沒有形成一個統一的方案。我們應用Smart Nic助力網絡轉型升級，更好地滿足公有雲、私有雲業務需求。

 

 五、參考鏈接  

1. http://www.mellanox.com/blog/2018/08/defining-smartnic/

2. http://www.mellanox.com/blog/2018/09/why-you-need-smart-nic-use-cases/

3. https://yq.aliyun.com/articles/604505

4.https://static.sched.com/hosted_files/lc32018/57/Zero-Copy%20Optimization%20for%20DPDK%20vhost-user%20Receiving_Jing%20Chen.pdf

5. http://www.mellanox.com/blog/2018/09/why-you-need-smart-nic-use-cases/