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

摘要： 這篇文章介紹了阿里云開發(fā)智能網(wǎng)卡的動機、功能框架和軟轉(zhuǎn)發(fā)程序，以及在軟轉(zhuǎn)發(fā)過程中發(fā)現(xiàn)的問題和優(yōu)化方法。

主講人：陳靜 阿里云高級技術(shù)專家

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

分論壇：Network & Orchestration

項目背景

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

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

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

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

Virtio or SRIOV？

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

?

?

我們結(jié)合virtio和SRIOV的優(yōu)勢，設計了一套基于軟轉(zhuǎn)發(fā)的方案。

?

智能網(wǎng)卡方案

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

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

報文接收路徑

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

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

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

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

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

優(yōu)化后的零拷貝接收

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

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

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

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

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

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

?

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

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

零拷貝的優(yōu)勢

經(jīng)過測試和分析，我們覺得零拷貝有如下的優(yōu)勢：

l???性能

• 接收端減少了內(nèi)存拷貝
  

• Footprint減少，避免cache-coherency
  

• 總體性能提高了40%
  

2、時延

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