DPU技術(shù)解決方案的挑戰(zhàn)和機(jī)遇

DPU 作為一種軟硬協(xié)同的虛擬化架構(gòu)，相較僅做網(wǎng)絡(luò)加速的智能網(wǎng)卡而言，一方面需要考慮與 CPU 中運(yùn)行的虛擬化軟件棧對(duì)接，另一方面由于 DPU 硬件的特殊設(shè)計(jì)導(dǎo)致卡與服務(wù)器存在更多的適配對(duì)接需求，因此 DPU 產(chǎn)業(yè)發(fā)展與軟硬件市場(chǎng)的配合度存在強(qiáng)關(guān)聯(lián)。能否理解行業(yè)需求，拉通軟硬件形成完整解決方案成為 DPU 發(fā)展與落地的關(guān)鍵。

當(dāng)前 DPU 解決方案百花齊放，在下表總結(jié)的業(yè)界主流 DPU 方案中，由于硬件路線選擇不同，DPU 卡的硬件設(shè)計(jì)存在較大差異，同時(shí)，各廠家均開(kāi)始布局自有配套軟件生態(tài)，并呈現(xiàn)出各自為營(yíng)的態(tài)勢(shì)。

縱觀處理器芯片幾十年的發(fā)展歷程，定制產(chǎn)品總是逐漸走向硬件形態(tài)的標(biāo)準(zhǔn)化和軟件生態(tài)的通用化，最終形成專用與通用并存的格局。DPU 作為繼 CPU、GPU 之后的第三顆數(shù)據(jù)中心核心處理器，基于自身虛擬化需求定制軟硬耦合DPU 產(chǎn)品固然能夠最大化發(fā)揮 DPU 產(chǎn)品優(yōu)勢(shì)，但是隨著更多的數(shù)據(jù)中心提出DPU 需求，這種方式的技術(shù)門(mén)檻和引入成本過(guò)高，難以復(fù)制。而商業(yè) DPU 產(chǎn)品由于各自發(fā)展軟件棧生態(tài)，也導(dǎo)致軟件與 DPU 適配對(duì)接的成本較高。同時(shí)，DPU與服務(wù)器整機(jī)的生態(tài)也不可忽視。

從物理關(guān)系上看，DPU 是掛載在服務(wù)器主 CPU下的 PCIe 子設(shè)備，但從頂層云管邏輯來(lái)看，DPU 是服務(wù)器的管理員，是提供數(shù)據(jù)加速、存儲(chǔ)加速、安全管控及云管的云底座。因此，不同于傳統(tǒng)網(wǎng)卡、HBA 卡、GPU 等標(biāo)準(zhǔn) PCIe 設(shè)備，主從關(guān)系的倒換使得 DPU 對(duì)傳統(tǒng)服務(wù)器硬件設(shè)計(jì)提出了特殊要求，主要體現(xiàn)在硬件供電、散熱適配、帶外管理、整機(jī)開(kāi)關(guān)機(jī)及異常處理策略等方面。

市場(chǎng)需求決定了 DPU 的軟硬件設(shè)計(jì)，而軟硬件的開(kāi)發(fā)、適配需要高昂的人力、財(cái)力成本投入，當(dāng)前專用化的 DPU 路徑不利于生態(tài)的發(fā)展，在百花齊放的行業(yè)現(xiàn)狀下更需要考慮通用性和標(biāo)準(zhǔn)化，拉通需求方、虛擬化軟件廠商、DPU 廠商與服務(wù)器廠商，形成端到端的閉環(huán)生態(tài)體系。

隨著需求越來(lái)越廣泛，技術(shù)的演進(jìn)對(duì) DPU 的落地帶來(lái)了諸多挑戰(zhàn)，關(guān)鍵挑戰(zhàn)即標(biāo)準(zhǔn)化程度對(duì) DPU 技術(shù)易用性的影響。

軟件系統(tǒng)標(biāo)準(zhǔn)化

與 CPU 和 GPU 這種先有硬件再有軟件生態(tài)的發(fā)展背景不同，DPU 承載的虛擬化軟件已經(jīng)較為成熟，DPU 在此基礎(chǔ)之上實(shí)現(xiàn)功能和性能的提升，因此對(duì)于業(yè)界云平臺(tái)以及 DPU 廠商來(lái)說(shuō)，DPU 能否規(guī)模部署取決于 DPU 配套軟件是否“能用”且“好用”。

中國(guó)移動(dòng)結(jié)合典型 DPU 應(yīng)用場(chǎng)景需求，分析 DPU 軟件部署方式，結(jié)合開(kāi)源社區(qū)方案成熟情況，給出 DPU 云化技術(shù)架構(gòu)管理、網(wǎng)絡(luò)、存儲(chǔ)、計(jì)算和安全五大系統(tǒng)軟件標(biāo)準(zhǔn)化建議，并結(jié)合中國(guó)移動(dòng)業(yè)務(wù)需求場(chǎng)景推動(dòng)軟件標(biāo)準(zhǔn)化階段式發(fā)展和落地：

一、管理系統(tǒng)：引入 DPU 后，計(jì)算節(jié)點(diǎn)上的管理系統(tǒng)軟件（OpenStack 等）安裝位置從主機(jī)側(cè) CPU 調(diào)整到 DPU 的 ARM 或 x86 核上。管理系統(tǒng)軟件主要實(shí)現(xiàn)虛擬硬件資源的邏輯管理功能，不使用 DPU 上的硬件加速引擎，因此理論上該部分軟件與 DPU 天然解耦，DPU 需支持管理系統(tǒng)軟件的編譯、安裝，可以通過(guò) DPU OS 和 Host OS 互通或者融合的方式，實(shí)現(xiàn)傳統(tǒng)云平臺(tái)管理軟件在 DPU上的無(wú)縫遷移部署和無(wú)感卸載，降低適配開(kāi)發(fā)成本。

虛擬化場(chǎng)景下，Libvirt 作為虛擬機(jī)管理組件也安裝在 DPU 上，OS 資源視圖發(fā)生變化，因此需要在主機(jī)側(cè)CPU 運(yùn)行輕量化代理完成主機(jī)資源和虛擬機(jī)管理。此時(shí)需要保證 Libvirt 管理面接口和原生 Libvirt 接口保持一致，同時(shí)支持接口的擴(kuò)展。裸金屬場(chǎng)景下，可采用 Ironic 組件或增強(qiáng) Nova 組件完成裸金屬管理，DPU 廠商可以提供標(biāo)準(zhǔn) IronicDriver 集成到云管理軟件中或適配標(biāo)準(zhǔn) Nova 管理流程，實(shí)現(xiàn)裸金屬生命周期的管理功能。

二、網(wǎng)絡(luò)系統(tǒng)：虛擬交換網(wǎng)絡(luò) vSwitch 控制面運(yùn)行在 DPU 的 CPU 核上，與SDN 控制器對(duì)接，生成流表規(guī)則并通過(guò) DPDK 標(biāo)準(zhǔn) rte_flow 完成流表向轉(zhuǎn)發(fā)面的下發(fā)，且需完成 bond 模式、mtu 值等數(shù)據(jù)通道參數(shù)的配置；轉(zhuǎn)發(fā)面運(yùn)行在 DPU的硬件加速引擎上，負(fù)責(zé)流表匹配邏輯的硬件實(shí)現(xiàn)，并為虛擬機(jī)、容器或裸金屬提供標(biāo)準(zhǔn)的 virtio 硬件后端。結(jié)合中國(guó)移動(dòng)現(xiàn)網(wǎng)需求，提出以下標(biāo)準(zhǔn)化要求：

?采用 DPDK 標(biāo)準(zhǔn) rte_flow 接口完成流表從控制面到轉(zhuǎn)發(fā)面的下發(fā)。同時(shí)考慮 NFV 業(yè)務(wù)網(wǎng)絡(luò)拓?fù)湫枨螅绕湓谂c終端用戶或基站通信時(shí)容易產(chǎn)生大規(guī)模流表瓶頸，影響轉(zhuǎn)發(fā)性能，因此需定制流表收斂方案，規(guī)避大流表場(chǎng)景問(wèn)題，同時(shí)降低業(yè)務(wù)倒換場(chǎng)景下流表下發(fā)通道阻塞的風(fēng)險(xiǎn)；

?增強(qiáng)運(yùn)維靈活性，業(yè)務(wù)網(wǎng)絡(luò)平面數(shù)據(jù)全部在硬件加速引擎完成接收與發(fā)送，因此需要在數(shù)據(jù)在硬件加速引擎的生命周期流程中增加入口與出口的運(yùn)維統(tǒng)計(jì)能力，便于故障分析定位，保證端到端可靠性；

?網(wǎng)絡(luò)接口采用用戶態(tài) vDPA 框架，在 DPU 上實(shí)現(xiàn) virtio 后端，同一站點(diǎn)資源池內(nèi)需統(tǒng)一要求 virtio 支持的 feature，以實(shí)現(xiàn)在部署不同廠商 DPU的計(jì)算節(jié)點(diǎn)之間的虛擬機(jī)熱遷移功能，保證云主機(jī)彈性特點(diǎn)。

RDMA 是超低時(shí)延網(wǎng)絡(luò)的關(guān)鍵技術(shù)，但是由于傳統(tǒng) Socket 編程模型和RDMA Verbs 編程模型差距顯著，導(dǎo)致傳統(tǒng)應(yīng)用遷移到 RDMA 網(wǎng)絡(luò)環(huán)境下需要進(jìn)行大量代碼改造，進(jìn)而給業(yè)務(wù)帶來(lái)不確定性風(fēng)險(xiǎn)或者可靠性風(fēng)險(xiǎn)，因此使用RDMA Socket 適配層屏蔽底層 RDMA 原語(yǔ)，向上對(duì)接 Socket 接口成為必然趨

勢(shì)，通過(guò)標(biāo)準(zhǔn)化的適配層，可以實(shí)現(xiàn)傳統(tǒng) Socket 應(yīng)用無(wú)縫遷移到 RDMA 網(wǎng)絡(luò)環(huán)境，在不改變業(yè)務(wù)代碼的情況下，提高業(yè)務(wù)的響應(yīng)時(shí)間和吞吐量。

三、存儲(chǔ)系統(tǒng)：包含存儲(chǔ)接口和存儲(chǔ)網(wǎng)絡(luò)協(xié)議兩部分?；陂_(kāi)源 SPDK 框架提供存儲(chǔ)卸載服務(wù)，利用 SPDK 的 JSON-RPC 配置接口，為虛擬機(jī)、裸機(jī)、容器提供一致的 virtio-blk/NVMe 虛擬塊設(shè)備后端，基于 bdev 層抽象虛擬磁盤(pán)并提供QoS、加密、壓縮、DIF、EC、RAID 等高級(jí)特性。存儲(chǔ)網(wǎng)絡(luò)協(xié)議方面，iSCSI 協(xié)議運(yùn)行在 DPU 上的 CPU 核上，需要支持標(biāo)準(zhǔn) iSCSI-Initiator 的編譯和安裝；NVMe-oF 由 DPU 硬件加速引擎實(shí)現(xiàn)，需要實(shí)現(xiàn) RoCEv2 等高性能 Fabric 網(wǎng)絡(luò)。

四、計(jì)算系統(tǒng)：主要為 Hypervisor 計(jì)算虛擬化系統(tǒng)的前后端分離，在計(jì)算節(jié)點(diǎn)需要對(duì) Hypervisor 軟件進(jìn)行合理的剪裁和卸載。主機(jī)側(cè)保留輕量化的Hypervisor 前端，KVM 完成 CPU 和內(nèi)存的虛擬化管理，DPU 側(cè)的 Hypervisor 后端配合 QEMU 完成虛擬機(jī)的初始化，并配合 Libvirt 完成虛擬機(jī)的生命周期管理。

Hypervisor 前后端對(duì)接應(yīng)標(biāo)準(zhǔn)化，同時(shí)需要對(duì)操作系統(tǒng)內(nèi)核進(jìn)行深度剪裁和修改，業(yè)界尚無(wú)參考模型，需要共同探索。

五、安全系統(tǒng)：DPU 可以提供節(jié)點(diǎn)出入口硬件級(jí)的數(shù)據(jù)加解密功能，通過(guò)虛擬化方式實(shí)現(xiàn)的分布式防火墻、DDoS 防御設(shè)備等安全應(yīng)用可以利用 DPU 硬件級(jí)的數(shù)據(jù)處理能力，提升安全應(yīng)用處理性能。此外針對(duì) HTTPS 等應(yīng)用層的加解密處理，需要提供統(tǒng)一的 API 接口來(lái)完成業(yè)務(wù)層用戶密鑰證書(shū)的管理。

針對(duì)以上五大系統(tǒng)在 DPU 上的卸載，OpenStack、DPDK、SPDK 等云計(jì)算虛擬化相關(guān)的主流開(kāi)源技術(shù)框架已經(jīng)逐步實(shí)現(xiàn)在 DPU 環(huán)境下的部署與應(yīng)用，當(dāng)前在裸金屬管理和虛擬交換網(wǎng)絡(luò)卸載兩類功能需求下已經(jīng)有較為成熟的技術(shù)方案。中國(guó)移動(dòng)軟件標(biāo)準(zhǔn)化推進(jìn)將分為兩個(gè)階段進(jìn)行：

?第一階段將聚焦于管理系統(tǒng)卸載、虛擬交換網(wǎng)絡(luò)的卸載、iSCSI 存儲(chǔ)網(wǎng)絡(luò)協(xié)議棧卸載，主要解決核心網(wǎng)網(wǎng)絡(luò)帶寬升級(jí)導(dǎo)致的 CPU 處理瓶頸和滿足彈性裸金屬云化管理需求，利用開(kāi)源技術(shù)方案，并增強(qiáng)平臺(tái)端到端可靠性，制定技術(shù)方案，形成企業(yè)標(biāo)準(zhǔn)，實(shí)施現(xiàn)網(wǎng)試點(diǎn)驗(yàn)證；

?第二階段將聚焦于 RDMA 技術(shù)及接口標(biāo)準(zhǔn)化、NVMe-oF 高性能存儲(chǔ)網(wǎng)絡(luò)協(xié)議卸載、Hypervisor 卸載、安全功能卸載等方面，滿足 AI 訓(xùn)練場(chǎng)景低時(shí)延網(wǎng)絡(luò)、大數(shù)據(jù)高性能存儲(chǔ)讀寫(xiě)、虛擬機(jī)“零”抖動(dòng)、零信任安全等場(chǎng)景下更為極致的性能需求，這些領(lǐng)域在業(yè)界尚無(wú)規(guī)模性商用案例和成熟技術(shù)方案，需要共同探索和推進(jìn)。

硬件系統(tǒng)標(biāo)準(zhǔn)化

當(dāng)前 DPU 內(nèi)除網(wǎng)絡(luò)、存儲(chǔ)卸載芯片外還會(huì)包含輕量級(jí)處理器芯片（或集成在其他芯片內(nèi)的處理器內(nèi)核）及帶外管理芯片，該部件可看作在服務(wù)器整機(jī)內(nèi)部的另一個(gè)小型服務(wù)器。在硬件標(biāo)準(zhǔn)化設(shè)計(jì)時(shí)，無(wú)論是對(duì)服務(wù)器自身還是承載的業(yè)務(wù)都應(yīng)該遵循最小影響原則做通用增強(qiáng)，梳理絕對(duì)必要項(xiàng)，約束服務(wù)器整機(jī)能為DPU 提供的最大能力。

從服務(wù)器整機(jī)角度，需重點(diǎn)考慮機(jī)構(gòu)設(shè)計(jì)、供電散熱和邊帶信號(hào)等方面的標(biāo)準(zhǔn)化工作：

?機(jī)構(gòu)設(shè)計(jì)：約束整機(jī)可支持卡的最大規(guī)格，避免異形卡及特殊機(jī)構(gòu)件，減少機(jī)構(gòu)適配工作量，減小應(yīng)力可靠性風(fēng)險(xiǎn)；

?供電散熱：在槽位供電及輔助供電方面，約束整機(jī)可支持卡在整機(jī) S5 狀態(tài)啟動(dòng)，滿足裸金屬場(chǎng)景云底座管理訴求，同時(shí)高度關(guān)注 DPU 因業(yè)務(wù)需要不斷增長(zhǎng)的最大功耗，謹(jǐn)慎討論并確定功耗門(mén)限；在配套散熱能力方面，約束整機(jī)支持 S5 狀態(tài)卡散熱及調(diào)速；

?邊帶信號(hào)：對(duì)于 PCIe 標(biāo)準(zhǔn)形態(tài)的 DPU 卡，在 PCIe 標(biāo)準(zhǔn)連接器定義基礎(chǔ)上，約束整機(jī)能夠提供給 DPU 的邊帶信號(hào)，落實(shí)信號(hào)類型、信號(hào)方向、電平、連接器選型、Pin 定義等細(xì)節(jié)，逐步引導(dǎo)行業(yè)做歸一化設(shè)計(jì)。

從 DPU 角度，業(yè)務(wù)的多樣性需求決定了當(dāng)前硬件形態(tài)的多樣化，行業(yè)內(nèi)存在如 PCIe 卡、OCP 卡、自定義扣卡等多種形態(tài)，結(jié)合服務(wù)器整機(jī)的標(biāo)準(zhǔn)化方向，需要考慮以下方面：

?關(guān)注服務(wù)器整機(jī)標(biāo)準(zhǔn)所能提供的機(jī)構(gòu)外框上限及功耗上限；

?避免主動(dòng)散熱器設(shè)計(jì)，并針對(duì)因高功耗引起的散熱片材質(zhì)升級(jí)進(jìn)行必要的力學(xué)前置仿真及后續(xù)測(cè)試；

?預(yù)留必要的調(diào)試接口（通過(guò)線纜接入到 BMC 或者前擋板直出）。

由于 DPU 上存在 CPU 核，因此可以看作服務(wù)器整機(jī)的第二系統(tǒng)，這種架構(gòu)的變化也導(dǎo)致服務(wù)器的帶外管理方式產(chǎn)生了變化，從 DPU 與服務(wù)器整機(jī)帶外管理交互角度，需要以下方面的標(biāo)準(zhǔn)化工作：

1. DPU BMC（或其他帶外管理模塊）具備的最小管理功能

2. 裸金屬場(chǎng)景服務(wù)器及 DPU 的上下電、復(fù)位、固件升級(jí)、異常下電、故障處理時(shí)的開(kāi)關(guān)機(jī)流程及軟件處理策略；

3. 云管業(yè)務(wù)對(duì)帶外信息抓取方案，定義裸金屬網(wǎng)卡 BMC 與主機(jī) BMC 的核心職責(zé)，細(xì)化兩者交互信息框架。

服務(wù)器整機(jī)硬件層面的標(biāo)準(zhǔn)化可讓通用服務(wù)器與各廠家 DPU 具備適配前提，掃清新生態(tài)發(fā)展中的技術(shù)障礙。在這一過(guò)程中，需共同探討 DPU 帶外管理系統(tǒng)與服務(wù)器整機(jī)帶外管理系統(tǒng)關(guān)系，明確 DPU BMC 應(yīng)具備的核心功能，逐步收斂雙 BMC 控制信息的交互框架，最終做到邊界清晰。

同時(shí)，中國(guó)移動(dòng)倡議各行業(yè)終端客戶關(guān)注因引入裸金屬服務(wù)引發(fā)的組網(wǎng)方式變革，立足自身業(yè)務(wù)特征探討網(wǎng)絡(luò)業(yè)務(wù)平面、存儲(chǔ)平面、帶內(nèi)管理平面、帶外 BMC 管理平面的處理方式，明確DPU 需提供的帶內(nèi)帶外網(wǎng)口規(guī)格及數(shù)量，為 DPU 廠商提供產(chǎn)品路標(biāo)。

審核編輯：郭婷