作者簡介：KIKI，中國科學(xué)院計算技術(shù)研究所在讀博士生

01引言

遠程直接內(nèi)存訪問（Remote Direct Memory Access，RDMA）技術(shù)允許應(yīng)用程序繞過操作系統(tǒng)內(nèi)核，以零拷貝的方式和遠程計算機進行網(wǎng)絡(luò)通信，具有低延遲和高帶寬的優(yōu)勢。RDMA協(xié)議主要包括Inifiband、RoCE以及iWARP。實現(xiàn)RDMA協(xié)議的I/O設(shè)備被稱為RNIC。主流云服務(wù)提供商已經(jīng)開始廣泛部署RNIC，例如亞馬遜云推出的彈性網(wǎng)絡(luò)適配器（Elastic Network Adapter，ENA）[1]。同時，云服務(wù)提供商通過硬件虛擬化技術(shù)對物理資源進行池化管理，提升資源效率。

硬件虛擬化（Virtualization）技術(shù)是一種計算機資源管理技術(shù)，在各類計算機硬件（例如CPU、內(nèi)存、存儲、網(wǎng)絡(luò)設(shè)備）上創(chuàng)建一個抽象層，將單個物理硬件資源模擬為多個虛擬資源。本文討論針對RDMA網(wǎng)卡（RDMA Network Interface Controller,RNIC）的虛擬化技術(shù)，即將一個RNIC模擬為多個RNIC供虛擬機（Virtual Machine，VM）使用。根據(jù)實現(xiàn)方式，I/O虛擬化可以分為直通，全虛擬化、半虛擬化以及基于硬件輔助的全虛擬化。

RNIC虛擬化方案既要維持RDMA的高性能優(yōu)勢，又要滿足云環(huán)境的部署要求。RDMA網(wǎng)絡(luò)相對于傳統(tǒng)TCP網(wǎng)絡(luò)的性能優(yōu)勢包括更低的延遲、更高的帶寬以及更低的CPU占用，因此針對RNIC的虛擬化方案首先應(yīng)該盡可能降低虛擬化引入的RDMA性能開銷。同時，云計算對虛擬實例之間的隔離性，虛擬實例的可遷移性以及虛擬實例的可管控性都有比較高的要求。本文針對虛擬機和容器兩種實體的典型RDMA虛擬化技術(shù)進行了調(diào)研，并且對相關(guān)領(lǐng)域的研究內(nèi)容進行了總結(jié)和展望。

02背景知識介紹

RDMA關(guān)鍵特征簡介

如Figure 1所示，RDMA技術(shù)采用了控制路徑（Control path）-數(shù)據(jù)路徑（Data path）分離的思想。RDMA的控制面包括設(shè)備管理，Queue Pair、Completion Queue、Memory Region等資源的管理，以及異常處理等功能。RDMA的數(shù)據(jù)面包括請求的發(fā)起以及請求的完成確認。RDMA用戶態(tài)的庫向應(yīng)用提供統(tǒng)一的、標(biāo)準(zhǔn)的動詞（Verbs）接口。Verbs接口定義了控制面和數(shù)據(jù)面的具體內(nèi)容，因此Verbs接口也可以進一步分為控制Verbs和數(shù)據(jù)Verbs?？刂芕erbs都會經(jīng)過內(nèi)核態(tài)RNIC驅(qū)動的轉(zhuǎn)發(fā)到達RNIC內(nèi)部的控制Verbs處理單元。控制Verbs和內(nèi)核驅(qū)動交互的過程涉及系統(tǒng)調(diào)用和上下文切換，被認為是慢路徑。數(shù)據(jù)Verbs通過內(nèi)存映射I/O的方式直接和RNIC內(nèi)部的數(shù)據(jù)Verbs處理單元交互。數(shù)據(jù)Verbs直接訪問RNIC的過程被認為是快路徑。RDMA的數(shù)據(jù)傳輸性能取決于數(shù)據(jù)Verbs的實現(xiàn)。

Figure 1 RDMA控制和數(shù)據(jù)路徑

RDMA數(shù)據(jù)Verbs的高性能依賴于數(shù)據(jù)傳輸過程中的零拷貝實現(xiàn)。零拷貝實現(xiàn)要求RNIC具有主動發(fā)起PCIe DMA直接讀寫應(yīng)用緩沖區(qū)的能力。應(yīng)用在RDMA數(shù)據(jù)傳輸中使用進程虛擬地址，然而PCIe DMA需要總線映射后的DMA地址。RNIC需要主動將應(yīng)用緩沖區(qū)的虛擬地址翻譯為DMA地址。在具體的實現(xiàn)中，RNIC會緩存應(yīng)用進程頁表的一部分到其管理的內(nèi)存翻譯表（Memory Translation Table，MTT）。在RDMA虛擬化的實現(xiàn)中，由于Guest OS中映射的DMA地址不一定連續(xù)，MTT表中的DMA地址需要由Hypervisor提供。

Figure 2 RNIC通過主動的內(nèi)存翻譯實現(xiàn)零拷貝傳輸

虛擬機和容器簡介

虛擬化技術(shù)使軟件應(yīng)用程序能夠運行在虛擬硬件（通過虛擬機和虛擬機監(jiān)控程序（Virtual Machine Monitor，VMM）實現(xiàn)虛擬化）或虛擬操作系統(tǒng)（通過容器（Container）實現(xiàn)虛擬化）上。虛擬機（VM），也稱為客戶機，是一個軟件模擬的硬件平臺，為客戶操作系統(tǒng)（Guest OS）提供虛擬操作環(huán)境。VMM也稱為Hypervisor，是一個運行在實際主機（Host）的軟件程序，監(jiān)督虛擬機上客戶操作系統(tǒng)的執(zhí)行。Hypervisor包括Type 1和Type 2兩類，其中Type 1 Hypervisor直接控制Host的硬件，而Type 2 Hypervisor通過Host操作系統(tǒng)間接控制硬件。目前主流的Hypervisor實現(xiàn)多屬于Type2，包括KVM，VMware以及VirtualBox等。容器是一個虛擬運行時環(huán)境集合，包含執(zhí)行目標(biāo)軟件應(yīng)用所需的所有資源（例如文件系統(tǒng)、CPU、內(nèi)存、進程空間以及網(wǎng)絡(luò)接口等）。

容器可以看作是對操作系統(tǒng)的虛擬化（也有觀點認為容器不能歸類到虛擬化技術(shù)），并不模擬底層硬件。相對于虛擬機，容器更加輕量化，啟動速度也更加快。容器引擎是運行容器的基礎(chǔ)環(huán)境，主流實現(xiàn)包括Docker以及LXC等。在容器規(guī)模比較大的情況，需要使用諸如Docker Swarm或Kubernetes（K8s）等容器編排（Containter Orchestration）工具管理容器的部署。

Figure 3 虛擬機和容器對比

03針對虛擬機的RDMA虛擬化技術(shù)

Figure 4 RDMA虛擬化技術(shù)發(fā)展歷程

最基礎(chǔ)的RNIC虛擬化方案是使用Hypervisor作為虛擬機和RNIC的唯一中間層，RDMA全部的數(shù)據(jù)和控制路徑的全部請求都被Hypervisor截獲、翻譯以及執(zhí)行，即全虛擬化I/O技術(shù)。如Figure 5所示，Hypervisor中的RDMA Proxy處理VM1和VM2的控制路徑和數(shù)據(jù)路徑。VM每次執(zhí)行RDMA相關(guān)操作都需要通過VM-Exit將控制權(quán)交給VMM，VMM處理完后再通過VM-entry重新進入到VM。全虛擬化具有靈活可控的優(yōu)勢，不需要為VM提供專有驅(qū)動，且云計算的各類要求可以在RDMA Proxy中實現(xiàn)。VM Exit/Entry過程涉及從VM到Hypervisor之間的上下文切換，會產(chǎn)生相當(dāng)大的性能開銷。由于全虛擬化的性能開銷較大，并未在工業(yè)界和學(xué)術(shù)界調(diào)查到基于全虛擬化技術(shù)的RNIC虛擬化方案。

Figure 5 全虛擬化RDMA實現(xiàn)示意

另外一種純軟件實現(xiàn)的虛擬化技術(shù)是半虛擬化（Paravirtualization），其由前端驅(qū)動和后端驅(qū)動共同模擬實現(xiàn)。在客戶機中運行的驅(qū)動程序稱之為前端（Frontend），在主機上與前端通信的驅(qū)動程序稱之為后端（Backend）。前端發(fā)送VM請求給后端，后端驅(qū)動處理完這些請求后再返回給前端。相對于全虛擬化，半虛擬化能夠減少VM Exit/Entry次數(shù)，性能相對提升。VMware公司提出的vRDMA [2]屬于半虛擬化RDMA方案，其整體架構(gòu)如Figure 6所示。vRDMA向Guest OS的RDMA應(yīng)用提供VMCI虛擬設(shè)備，libvrdma是VMCI虛擬設(shè)備的用戶態(tài)驅(qū)動，vRDMA Driver是VMCI虛擬設(shè)備的用戶態(tài)驅(qū)動。同時，VRDMA Driver也是半虛擬化框架中的前端驅(qū)動，后端驅(qū)動是Hypervisor中的vRDMA VMCI Endpoint。vRDMA VMCI Endpoin最終通過RDMA內(nèi)核Verbs調(diào)用RDMA內(nèi)核態(tài)驅(qū)動。

Figure 6 VMvare vRDMA實現(xiàn)架構(gòu)

硬件輔助虛擬化包括直通和SR-IOV兩種主流方案。RNIC以一個PCIe設(shè)備的形式接入到現(xiàn)有系統(tǒng)，因此最基礎(chǔ)的硬件輔助RNIC虛擬化方案是采用Intel VT-D或者AMD Vi技術(shù)將RNIC直接綁定到一個虛擬機，這種虛擬化方法也被稱為直通（Passthrough）。直通方式能夠使得虛擬機獨占RNIC，RNIC性能可以實現(xiàn)零損耗。然而一臺主機上會存在多個虛擬機，如果采用直通方式實現(xiàn)RNIC虛擬化，則主機上安裝的RNIC數(shù)量需要和主機最大支持虛擬機數(shù)量相等。顯然，直通方式的并不具備虛擬機層面的可擴展性。SR-IOV（Single Root Input/Output Virtualization）技術(shù)能夠?qū)⒁粋€物理PCIe設(shè)備模擬成多個虛擬的PCIe設(shè)備（基于SR-IOV引入的Virtual Function，VF），專門用于針對VM的網(wǎng)卡虛擬化。根據(jù)OSU大學(xué)公開的性能評估結(jié)果 [3]，SR-IOV虛擬化RDMA的小消息延遲相對于非虛擬化RDMA只增加了0.5us~1us，大消息延遲和非虛擬化RDMA無明顯差距。此外，基于SR-IOV的虛擬化RDMA和非虛擬化RDMA的可達帶寬無明顯差距。Purdue大學(xué)的Malek等人 [4]提出了針對SR-IOV虛擬化RDMA的參數(shù)（例如中斷聚合閾值、共享接收隊列水線）優(yōu)化方法，進一步減小了SR-IOV虛擬化RDMA和非虛擬化RDMA的性能差距。僅就RDMA虛擬化的性能而言，SR-IOV可以被認為是最優(yōu)的選擇。然而SR-IOV并不靈活，不能滿足云計算的可遷移性和可管控性要求。例如，Mellanox ConnextX-4/5/6系列RNIC在重新配置SR-IOV的VF數(shù)量時需要首先將VF數(shù)量清零 [5]，清零意味著當(dāng)前正使用VF的VM需要放棄其對應(yīng)的虛擬RNIC。假設(shè)當(dāng)前主機RNIC的SR-IOV配置了4個VF，因為業(yè)務(wù)需求需要從其他主機遷入一個VF，則需要將SR-IOV的VF數(shù)量重新配置為8，則當(dāng)前4個VM都需要放棄其虛擬RNIC。此外，基于SR-IOV的虛擬化方案需要在RDMA網(wǎng)卡內(nèi)部集成支持虛擬網(wǎng)絡(luò)的2層交互模塊（L2 Switch），在將VM從一個主機熱遷移到另外一個主機時需要重新配置L2 Switch，硬件重配置通常被認為是不靈活的。

Figure 7 基于Passthrough和SR-IOV虛擬化方案對比

混合虛擬化利用了RDMA設(shè)計中的控制-數(shù)據(jù)路徑分離的特點，對控制路徑使用半虛擬化，對數(shù)據(jù)路徑采用基于內(nèi)存映射的硬件直通。IBM研究人員提出的HyV [6]是混合虛擬化的代表案例，相應(yīng)的論文發(fā)表在2015年的VEE會議。在控制路徑上，VM中的前端驅(qū)動攔截用戶態(tài)驅(qū)動的ibv_create_qp, ibv_create_cq等控制Verbs轉(zhuǎn)發(fā)到到Hypervisor中的后端驅(qū)動。后端驅(qū)動對接受到的控制Verbs調(diào)用實現(xiàn)VM層面的隔離、安全以及資源管控等要求后，將控制Verbs轉(zhuǎn)發(fā)給RNIC設(shè)備驅(qū)動。在后端驅(qū)動中，內(nèi)存映射相關(guān)的控制路徑需要實現(xiàn)1）將RNIC提供的隊列門鈴映射到VM進程的地址空間；2）QP等資源占用的內(nèi)存在后端驅(qū)動的地址空間分配，需要映射到VM進程的地址空間；3）VM進程數(shù)據(jù)緩沖區(qū)對應(yīng)的Guest VA到Host PA映射需要同步到RNIC。在數(shù)據(jù)路徑上，應(yīng)用通過映射后的門鈴和直接和RNIC交互，實現(xiàn)post_send，post_recv以及poll_cq。在具體實現(xiàn)上，HyV使用成熟的Virtio框架實現(xiàn)了控制路徑的前后端驅(qū)動。實驗評估顯示HyV的性能和SR-IOV相近，在資源管理的靈活性上接近半虛擬化。微軟提出的Endure（Enlighteded Network Direct On Azure） [7]以及華為提出的virtio-RDMA [8]都沿用了類似HyV的設(shè)計。在具體的實現(xiàn)上，Endure采用自定義的VMBus實現(xiàn)控制路徑Guest-Host交互，而不是沿用virtio。Virtio-RDMA將HyV的前端驅(qū)動重新實現(xiàn)在Guest OS的用戶態(tài)，減少上下文切換的次數(shù)。

以HyV為代表的RDMA混合虛擬化提出后，通過半虛擬化實現(xiàn)控制面和通過內(nèi)存映射方式實現(xiàn)數(shù)據(jù)面直通硬件的方案已經(jīng)成為共識。如何改造繼續(xù)改造RDMA虛擬化方案，使得其更好地適應(yīng)云計算特定的需求成為新的研究關(guān)注的。例如華為在SGICOMM 2021提出的MasQ [9]，進一步在虛擬化控制面強化了租戶隔離、安全隔離以及服務(wù)質(zhì)量的設(shè)計，使得虛擬化RDMA能夠在VPC（Virtual Private Cloud）網(wǎng)絡(luò)部署。

Figure 8 HyV混合虛擬化和半虛擬對比

04針對容器的RDMA虛擬化技術(shù)

容器可以看作是在主機操作系統(tǒng)上執(zhí)行的進程，由主機操作系統(tǒng)提供資源隔離和命名空間（Namespace）的隔離。Namespace是Linux內(nèi)核提供的資源隔離技術(shù)，可以實現(xiàn)網(wǎng)絡(luò)、文件系統(tǒng)以及進程資源等的隔離。針對容器的RDMA虛擬化技術(shù)，本質(zhì)上是在網(wǎng)絡(luò)Namespace的基礎(chǔ)上創(chuàng)建虛擬RDMA設(shè)備接口的過程。針對虛擬機的RDMA虛擬化技術(shù)是可以直接遷移到容器上的。Mellanox公司在2018年推出出了針對Docker容器網(wǎng)絡(luò)設(shè)備SR-IOV和Passthrough插件 [10]，該插件能夠在容器內(nèi)部創(chuàng)建虛擬RDMA設(shè)備或?qū)⑽锢碓O(shè)備綁定到某一個具體的容器。此外，Mellanox SR-IOV/Passthrough插件還利用網(wǎng)卡的的VLAN卸載功能對容器提供基于VLAN的虛擬網(wǎng)絡(luò)支持。

SR-IOV能夠提供良好的性能，但是不能完全滿足云計算所需要的靈活性需求。特別地，容器對虛擬化方案的靈活性需求更高，現(xiàn)有研究工作主要從這個角度入手。微軟的研究人員認為基于SR-IOV的虛擬化方案不能滿足容器需要的便攜性（Portability）要求。在基于SR-IOV的方案種，更新容器的IP需要同時更新網(wǎng)卡上的VLAN路由表。此外，基于SR-IOV的方案使得容器可以直接訪問物理RDMA網(wǎng)卡，云服務(wù)提供商不能靈活地對容器的RDMA業(yè)務(wù)進行管控。

FreeFlow [11]是微軟提出的容器虛擬化方案，該方案包括FreeFlow NetLib、FreeFlow Router以及FreeFlow Orchestrator。FreeFlow可以看作是半虛擬化設(shè)計，F(xiàn)reeFlow Netlib相當(dāng)于容器內(nèi)部的前端，而FreeFlow Router相當(dāng)于主機上的后端。FreeFlow Netlib以標(biāo)準(zhǔn)的用戶態(tài)Verbs API作為基礎(chǔ)，從而保持對應(yīng)用透明。FreeFlow Netlib通過劫持控制路徑上的RNIC文件描述符請求，避免直接劫持Verbs API調(diào)用帶來的RDMA數(shù)據(jù)結(jié)構(gòu)序列化復(fù)雜度。FreeFlow Netlib將劫持到的RNIC文件描述符請求通過Unix Socket File Descriptor或者共享內(nèi)存的方式轉(zhuǎn)發(fā)到FreeFlow Router。FreeFlow Netlib和FreeFlow Router都是兩個進程，通過Unix Socket File Descriptor可以實現(xiàn)兩個進程之間的通信，但是這種通信方式延遲開銷在5us以上，不能維持RDMA的低延遲要求。FreeFlow同時設(shè)計了基于共享內(nèi)存的進程間通信方式，這種通信延遲低但是需要CPU資源輪詢共享內(nèi)存。FreeFlow Route是位于主機的一個進程，代替同一主機上的容器和物理RDMA網(wǎng)卡交互。為了實現(xiàn)數(shù)據(jù)路徑上的零拷貝，F(xiàn)reeFlow Router將其內(nèi)部的共享數(shù)據(jù)緩沖區(qū)（Shared Memory）和容器內(nèi)應(yīng)用緩沖區(qū)映射到同一塊物理內(nèi)存。為了實現(xiàn)這種映射，F(xiàn)reeFlow提供主動分配和被動重映射的方法。主動分配方法需要應(yīng)用主動調(diào)用FreeFlow自定義的ibv_malloc和ibv_free接口分配和釋放FreeFlow Router內(nèi)部預(yù)留的Shared Memory。被動重映射需要FreeFlow Netlib在FreeFlow Router處理完內(nèi)存注冊請求后，將應(yīng)用通過malloc申請的內(nèi)存物理頁重新映射到FreeFlow Router返回的Shared Memory。FreeFlow Orchestrator負責(zé)集群內(nèi)全部容器的網(wǎng)絡(luò)編排，例如編址、訪問控制。此外，F(xiàn)reeFlow Orchestrator還需要管理容器內(nèi)應(yīng)用緩沖區(qū)虛擬地址到FreeFlow Router內(nèi)部Shared Memory指針的映射關(guān)系。

Figure 9 FreeFlow的總體架構(gòu)

在標(biāo)準(zhǔn)的容器生產(chǎn)中，容器網(wǎng)絡(luò)接口應(yīng)遵循云原生計算基金會（Cloud Native Computing Foundation，CNCF）規(guī)定的容器網(wǎng)絡(luò)接口（Container Network Interface，CNI）規(guī)范 [12]，然而FreeFlow和CNI標(biāo)準(zhǔn)并不兼容。Mellanox在2021年推出了針對K8s容器編排平臺的CNI插件RDMA CNI plugin [13]，使得基于SR-IOV的RDMA網(wǎng)絡(luò)設(shè)備資源池能夠集成到K8s。Container Runtime (例如Docker)在創(chuàng)建容器時，先創(chuàng)建好Network Namespace (netns)，然后調(diào)用RDMA CNI plugin為這個netns配置RDMA網(wǎng)絡(luò)，其后再啟動容器內(nèi)的應(yīng)用。

Figure 10 CNI插件關(guān)系圖

05總結(jié)與展望

本文分別從虛擬機和容器2個方面闡述了對RDMA虛擬化的相關(guān)研究。從虛擬機角度來看，以HyV為代表的混合虛擬化方案利用了RDMA控制-數(shù)據(jù)分離的設(shè)計特征，能夠在控制面的靈活性和數(shù)據(jù)面的性能上取得很好的權(quán)衡。未來的研究應(yīng)該重點關(guān)注控制面的靈活性，面向云計算業(yè)務(wù)實際需求優(yōu)化。從容器角度來看，容器和物理RDMA網(wǎng)卡之間的軟件中間層比虛擬機更輕薄，但是容器網(wǎng)絡(luò)的復(fù)雜性是要高于虛擬機的，同時容器的規(guī)模也要比虛擬機大。容器網(wǎng)絡(luò)和容器規(guī)模要求網(wǎng)絡(luò)2層交換層具有高靈活性，高可擴展性，因此目前主流的SR-IOV的容器虛擬化方案必須要在網(wǎng)卡硬件上實現(xiàn)滿足容器部署需求的交換層。DPU上同時具備了靈活可編程網(wǎng)絡(luò)引擎，RDMA引擎以及SR-IOV的支持，有潛力能夠在性能、靈活性以及可擴展性層面取得比較好的權(quán)衡。