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

01引言

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

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

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

02背景知識(shí)介紹

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

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

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

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

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

虛擬機(jī)和容器簡(jiǎn)介

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

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

Figure 3 虛擬機(jī)和容器對(duì)比

03針對(duì)虛擬機(jī)的RDMA虛擬化技術(shù)

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

最基礎(chǔ)的RNIC虛擬化方案是使用Hypervisor作為虛擬機(jī)和RNIC的唯一中間層，RDMA全部的數(shù)據(jù)和控制路徑的全部請(qǐng)求都被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重新進(jìn)入到VM。全虛擬化具有靈活可控的優(yōu)勢(shì)，不需要為VM提供專有驅(qū)動(dòng)，且云計(jì)算的各類要求可以在RDMA Proxy中實(shí)現(xiàn)。VM Exit/Entry過程涉及從VM到Hypervisor之間的上下文切換，會(huì)產(chǎn)生相當(dāng)大的性能開銷。由于全虛擬化的性能開銷較大，并未在工業(yè)界和學(xué)術(shù)界調(diào)查到基于全虛擬化技術(shù)的RNIC虛擬化方案。

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

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

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

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

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

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

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

Figure 8 HyV混合虛擬化和半虛擬對(duì)比

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

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

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

FreeFlow [11]是微軟提出的容器虛擬化方案，該方案包括FreeFlow NetLib、FreeFlow Router以及FreeFlow Orchestrator。FreeFlow可以看作是半虛擬化設(shè)計(jì)，F(xiàn)reeFlow Netlib相當(dāng)于容器內(nèi)部的前端，而FreeFlow Router相當(dāng)于主機(jī)上的后端。FreeFlow Netlib以標(biāo)準(zhǔn)的用戶態(tài)Verbs API作為基礎(chǔ)，從而保持對(duì)應(yīng)用透明。FreeFlow Netlib通過劫持控制路徑上的RNIC文件描述符請(qǐng)求，避免直接劫持Verbs API調(diào)用帶來的RDMA數(shù)據(jù)結(jié)構(gòu)序列化復(fù)雜度。FreeFlow Netlib將劫持到的RNIC文件描述符請(qǐng)求通過Unix Socket File Descriptor或者共享內(nèi)存的方式轉(zhuǎn)發(fā)到FreeFlow Router。FreeFlow Netlib和FreeFlow Router都是兩個(gè)進(jìn)程，通過Unix Socket File Descriptor可以實(shí)現(xiàn)兩個(gè)進(jìn)程之間的通信，但是這種通信方式延遲開銷在5us以上，不能維持RDMA的低延遲要求。FreeFlow同時(shí)設(shè)計(jì)了基于共享內(nèi)存的進(jìn)程間通信方式，這種通信延遲低但是需要CPU資源輪詢共享內(nèi)存。FreeFlow Route是位于主機(jī)的一個(gè)進(jìn)程，代替同一主機(jī)上的容器和物理RDMA網(wǎng)卡交互。為了實(shí)現(xiàn)數(shù)據(jù)路徑上的零拷貝，F(xiàn)reeFlow Router將其內(nèi)部的共享數(shù)據(jù)緩沖區(qū)（Shared Memory）和容器內(nèi)應(yīng)用緩沖區(qū)映射到同一塊物理內(nèi)存。為了實(shí)現(xiàn)這種映射，F(xiàn)reeFlow提供主動(dòng)分配和被動(dòng)重映射的方法。主動(dòng)分配方法需要應(yīng)用主動(dòng)調(diào)用FreeFlow自定義的ibv_malloc和ibv_free接口分配和釋放FreeFlow Router內(nèi)部預(yù)留的Shared Memory。被動(dòng)重映射需要FreeFlow Netlib在FreeFlow Router處理完內(nèi)存注冊(cè)請(qǐng)求后，將應(yīng)用通過malloc申請(qǐng)的內(nèi)存物理頁重新映射到FreeFlow Router返回的Shared Memory。FreeFlow Orchestrator負(fù)責(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)遵循云原生計(jì)算基金會(huì)（Cloud Native Computing Foundation，CNCF）規(guī)定的容器網(wǎng)絡(luò)接口（Container Network Interface，CNI）規(guī)范 [12]，然而FreeFlow和CNI標(biāo)準(zhǔn)并不兼容。Mellanox在2021年推出了針對(duì)K8s容器編排平臺(tái)的CNI插件RDMA CNI plugin [13]，使得基于SR-IOV的RDMA網(wǎng)絡(luò)設(shè)備資源池能夠集成到K8s。Container Runtime (例如Docker)在創(chuàng)建容器時(shí)，先創(chuàng)建好Network Namespace (netns)，然后調(diào)用RDMA CNI plugin為這個(gè)netns配置RDMA網(wǎng)絡(luò)，其后再啟動(dòng)容器內(nèi)的應(yīng)用。

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

05總結(jié)與展望

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