摘要：?摘要 這篇文章介紹了阿里云開發智能網卡的動機、功能框架和軟轉發程序以及在軟轉發過程中發現的問題和優化方法。 主講人陳靜 阿里云高級技術專家 主題Zero-copy Optimization for DPDK vhost-user Receiving 分論壇Network & Orchestration 項目背景 在VPC產品部署中虛擬交換Virtual Switch承擔著overlay層和underlay層進行網絡協議的加解密encap/decap功能在多租戶虛擬機或者容器的主機上也需要進行二三層的路由轉發、Qos、限流、安全組等。

摘要： 這篇文章介紹了阿里云開發智能網卡的動機、功能框架和軟轉發程序，以及在軟轉發過程中發現的問題和優化方法。

主講人：陳靜 阿里云高級技術專家

主題：Zero-copy Optimization for DPDK vhost-user Receiving

分論壇：Network & Orchestration

項目背景

在VPC產品部署中，虛擬交換（Virtual Switch）承擔著overlay層和underlay層進行網絡協議的加解密（encap/decap）功能；在多租戶（虛擬機或者容器）的主機上，也需要進行二三層的路由轉發、Qos、限流、安全組等。虛擬交換現在業界有比較被廣泛接受的OVS開源項目，在阿里云上，我們也開發了針對自身業務相契合的AVS項目。AVS有和OVS類似的功能，也同樣是純軟件的實現方式，在我們使用過程中，發現了一些問題，從而催生了智能網卡項目。

首先，AVS占用主機資源。AVS作為軟件，需要占用主機側的計算資源、內存資源，當吞吐量大時，還會占用大量的LLC cache資源，而本來這些資源更好的利用方式是交給客戶，增加資源的利用率。

其次，性能瓶頸。在云上業務部署過程中，應用對網絡帶寬的要求在不斷提高，純軟件的方式已經慢慢跟不上這種需求，因此有必要用對AVS進行加速。

基于這兩個原因，我們進行了智能網卡項目。

Virtio or SRIOV？

眾所周知采用PCI-E SRIOV技術的VF設備，通過PASS-THROUGH的方式呈現在VM，具有高性能、功能豐富的特點。但是缺點也同樣明顯，比如熱遷移（hot-plug）不方便；不同廠家提供的VF接口不一致；需要額外的驅動等等。virtio作為業界比較通用的一種虛擬設備接口方式可以解決之上的各種問題，但是問題在于目前暫時沒有完全支持virtio接口設備的硬件廠商，其是使用軟件模擬實現的一種方式，因此性能不是很好。那么，有沒有一種又有高性能，同時支持virtio的解決方案呢？

?

?

我們結合virtio和SRIOV的優勢，設計了一套基于軟轉發的方案。

?

智能網卡方案

下圖是我們的智能網卡的框架設計，在卡上有一個標準的網卡ASIC和一個片上系統，片上系統自帶內存和CPU。AVS運行在片上系統，把快速路徑（fast-path）卸載到ASIC中，而自身只負責慢速路徑（slow-path）的處理。通過快慢速路徑分離的方式，不但減輕了軟件AVS的處理負載，也大大提高了吞吐率。

在智能網卡實現過程中，由于我們的標卡沒法做到virtio-net的硬化，所以對host的輸出只是一個提供商定義（vendor-specific）的VF接口。同時，在客戶側（VM
），我們期望用戶不用做任何的修改，沿用virtio-net接口。在這種需求下，我們開發了一個簡單的、基于DPDK的軟轉發程序。由于AVS在網卡已經完成了所有的策略、邏輯、路由、多隊列的所有功能，VF和virtio-net前端有一一對應的關系，而軟轉發程序只需要完成VF和virtio-net的接口轉換和報文傳遞即可。同時，我們也不能為該軟轉發程序分配很多資源，否則就和我們最初做智能網卡的初衷背道而馳。因此，軟轉發的性能成為了我們非常重要考量的指標。在描述我們的優化方法之前，我們先了解一下常規路徑。

報文接收路徑

在講到報文接收路徑之前，有必要介紹一下DPDK中接收隊列的初始化方式。首先，軟件需要在內存中分配一段緩沖區作為隊列，隊列中的數據結構稱為描述符（descriptor），這是軟件和硬件交互的接口；如果是virtio-net這中para-virtualized模擬設備，前端驅動和后端驅動交互的接口。除此之外，軟件還需要一個內存池（memory pool），里面都是固定大小的數據緩沖區，用來承載網卡發送過來的網絡報文。

初始化接收隊列之后，網卡就可以開始正常工作了。當從網絡中接收到報文之后，按照下圖所示進行處理，最終送達到對應的虛擬機。

首先，報文緩存在智能網卡上，然后進行快速路徑或者慢速路徑的處理，最終判斷是發送到哪一個VF，哪一個接收隊列。

接著，網卡會從對應的VF接收隊列讀取描述符，獲得存儲報文的地址，然后進行DMA操作，最后，回寫描述符到接收隊列，描述符中包含了報文長度、類型、錯誤標志位等信息。

軟轉發程序通過VF接收隊列的描述符發現收到了一個報文，接著會讀取VM中的virtio-net的接收隊列描述符，獲得需要拷貝的虛機中的DMA數據地址，通過memcpy的方式拷貝報文；接著，更新virtio-net的描述符信息，通知前端驅動，整個邏輯完成。

優化后的零拷貝接收

從之上的過程可以發現在報文送到虛擬機的整個路徑中，報文被拷貝了兩次：一次是硬件DMA到主機內存，另外一次是軟轉發程序拷貝報文到虛擬機的Guest memory。特別是后一次是非常消耗CPU時間的操作。從我們后來的性能profiling也可以看到內存拷貝占用了很大的比例。那么，能不能減少一次拷貝呢？

綜合以上的需求，我們設計了接收端的零拷貝方案。主要是設計了一個隊列同步模塊，如下所示。

它主要的作用有以下幾個：

1.???????在前端virtio-net和SRIOV VF隊列的描述建立1：1的映射關系。

2.???????監控前端virtio-net 接受隊列描述符的改變，同步到VF的接收隊列中。這樣，在VF的接受隊列中就不需要內存池來緩存從網卡上收到的報文，而直接用虛擬機傳遞的緩存。

3.???????進行虛機物理地址（Guest Physical Address, GPA）到主機物理地址（Host Physical Address, HPA）的轉換。在virtio-net的VF中，驅動填充的是GPA地址，在沒有利用IOMMU的情況下，需要把GPA轉換成HPA，這樣智能網卡才能進行DMA傳送。

?

在有了隊列同步模塊之后，報文的接收過程如下圖所示。

主要改進在于智能網卡直接DMA到虛擬機指定的內存中去，并且硬件還不感知這個變化。軟轉發程序只是簡單的將VF接受隊列的描述符信息進行轉換，填充到前端virtio-net的接受隊列中去。

零拷貝的優勢

經過測試和分析，我們覺得零拷貝有如下的優勢：

l???性能

• 接收端減少了內存拷貝
  

• Footprint減少，避免cache-coherency
  

• 總體性能提高了40%
  

2、時延

• 減少拷貝帶來的時間開銷