您在說明書中常?？吹健叭ズ缺Х取眴?？作為一名開發(fā)人員，我很早就發(fā)現(xiàn)這種令人生厭的俏皮話是我生活中的禍根。無論持續(xù)時(shí)間長短，進(jìn)程切換（Context Switches）在應(yīng)用程序開發(fā)周期中都是一項(xiàng)高昂的成本。在所有需要您離開的步驟中，等待應(yīng)用程序編譯是最難擺脫的。

當(dāng)我們進(jìn)入 NVIDIA BlueField DPU 應(yīng)用程序開發(fā)的新世界，有效地設(shè)置構(gòu)建步驟非常重要，以便您能夠無縫地編碼→編譯→單元測試。在本文中，我介紹了 DPU 編譯應(yīng)用程序的不同方法。

DOCA 數(shù)據(jù)平面插件的 FRR

（Free Range Routing）

在 DPU 應(yīng)用程序開發(fā)系列文章中，我談到了在 FRR 中創(chuàng)建 DOCA 數(shù)據(jù)平面插件以用于卸載策略。FRR 的代碼行數(shù)接近 100 萬行（ 789678 SLOC ），這使得它成為衡量構(gòu)建時(shí)間的絕佳候選。

直接在 BlueField DPU 上開發(fā)

DPU 具有 Arm64 架構(gòu)，一種快速啟動(dòng) DPU 應(yīng)用程序的方法就是直接在 DPU 上開發(fā)。本測試使用具有 8G RAM 和 8 個(gè) A72 CPU 內(nèi)核的 NVIDIA BlueField2 DPU 。

我安裝了 BlueField 引導(dǎo)文件（ BFB ），它為 DPU 提供 Ubuntu 20.04.3 操作系統(tǒng)映像。它還包括 DOCA 1.2 和 DPDK 20.11.3 庫。為了使用 DOCA 庫構(gòu)建應(yīng)用程序，我將 DPDK pkgconfig 位置添加到 PKG_CONFIG 路徑。

接下來，我通過克隆 FRR 在 DPU 上設(shè)置了我的代碼工作區(qū)，并切換到 DOCA 數(shù)據(jù)平面插件。

FRR 需要一個(gè)不斷發(fā)展的先決條件列表，這些先決條件列舉在 FRR 社區(qū)文檔中。安裝了這些依賴項(xiàng)后，我將 FRR 配置為包括 DPDK 和 DOCA 數(shù)據(jù)平面插件。

當(dāng)我使用 DPU 作為我的開發(fā)環(huán)境時(shí)，我構(gòu)建并安裝了 FRR 二進(jìn)制文件：

以下是構(gòu)建時(shí)間的表現(xiàn)。我用多種方法來衡量：

使用 make -j12 all 和 make install 構(gòu)建和安裝二進(jìn)制文件的時(shí)候

使用 dpkg-buildpackage –j12 –uc –us 將它們組裝成 Debian 軟件包來構(gòu)建相同二進(jìn)制文件的時(shí)候

第一種方法用于編碼和單元測試。第二種生成 deb 的方法需要與其他外部開發(fā)環(huán)境上的構(gòu)建時(shí)間進(jìn)行比較。

表 1 。 DPU Arm 構(gòu)建時(shí)間

時(shí)間上的差異是意料之中的。生成一個(gè)包需要幾個(gè)額外的步驟。

使用 DPU 作為開發(fā)環(huán)境有一些明顯的優(yōu)勢：

您可以在不離開工作區(qū)的情況下進(jìn)行編碼、構(gòu)建和安裝，然后進(jìn)行單元測試。

您可以針對增量代碼更改來優(yōu)化構(gòu)建。

與完整構(gòu)建（Complete make）相比，最后一個(gè)選擇通?？梢源蠓s短構(gòu)建時(shí)間。例如，我在 FRR 中修改了 DOCA 數(shù)據(jù)平面代碼，并重建的結(jié)果如下：

雖然這可能會(huì)讓事情變得更簡單，但它需要為每個(gè)開發(fā)人員無限期的保留 DPU ，僅用于應(yīng)用程序開發(fā)或維護(hù)。您的開發(fā)環(huán)境可能還需要更多的內(nèi)存和性能，因此長期來看，這是一個(gè)不太可行的選擇。

在 x86 服務(wù)器上開發(fā)

我的 BlueField-2 DPU 由一臺(tái) x86-64 Ubuntu 20.04 服務(wù)器托管，我將這臺(tái)服務(wù)器用于我的開發(fā)環(huán)境。

在本例中，構(gòu)建機(jī)器是 x86 ，應(yīng)用程序?qū)⑦\(yùn)行的主機(jī)是 DPU-Arm64 。有幾種方法可以做到這一點(diǎn)：

在 x86 構(gòu)建機(jī)器上使用 Arm 仿真。 提供的 DOCA 開發(fā)容器 作為 DOCA 軟件包的一部分。

使用交叉編譯工具鏈。

在這個(gè)測試中，我使用了第一個(gè)選項(xiàng)，因?yàn)樗亲詈唵蔚摹５诙€(gè)選項(xiàng)可以提供不同的性能，但創(chuàng)建該工具鏈有其挑戰(zhàn)。

我在x86 服務(wù)器上下載并加載了 bfb_builder_doca_ubuntu_20.04 容器，并啟動(dòng)了它。

DOCA 和 DPDK 庫預(yù)先安裝在這個(gè)容器中，我只需要將它們添加到 PKG_CONFIG 路徑。

我在容器中設(shè)置了工作區(qū)和 FRR 先決條件，與前面的選項(xiàng)相同。

我可以在這個(gè) DOCA 容器中構(gòu)建我的應(yīng)用程序，但我無法對其進(jìn)行測試。因此，必須將 FRR 二進(jìn)制文件構(gòu)建并打包到 deb 中，然后將其復(fù)制到 BlueField DPU 進(jìn)行測試。我設(shè)置了 FRR Debian 規(guī)則，以匹配前面選項(xiàng)中使用的 FRR 構(gòu)建配置，并生成了軟件包：

表 2 顯示了構(gòu)建時(shí)間與以前方法的比較：

表 2 。 DPU Arm 和 X86 構(gòu)建時(shí)間

構(gòu)建時(shí)間的大幅增加讓我感到驚訝，因?yàn)槲矣幸慌_(tái)充足 x86 資源的服務(wù)器，而且沒有 Docker 限制。因此，將 CPU 和 RAM 用于解決問題似乎并不總是有幫助的！這種性能下降是因?yàn)榭珞w系結(jié)構(gòu)造成的，正如您在下一個(gè)選項(xiàng)中看到的那樣。

在 AWS Graviton 實(shí)例中開發(fā)

接下來，我嘗試在 Arm 上構(gòu)建我的應(yīng)用程序，但這次是在性能更大的外部服務(wù)器上。為此，我使用了 Amazon EC2 Graviton 實(shí)例，其規(guī)格與我的 x86 服務(wù)器相當(dāng)。

Arm 64 arch ， Ubuntu 20.04 操作系統(tǒng)

128G 內(nèi)存

32 vCPU

為了在這個(gè)實(shí)例中設(shè)置 DOCA 和 DPDK 庫，我安裝了 DOCA SDK repo meta 包 。

克隆和構(gòu)建 FRR Debian 軟件包的其余步驟與前面的選項(xiàng)相同。

表 3 顯示了構(gòu)建在 AWS Arm 實(shí)例上的運(yùn)行情況：

表 3 。 DPU Arm 、X86 和 AWS Arm 的構(gòu)建時(shí)間

這是一個(gè)明顯的贏家，不需要咖啡。

圖 1 顯示了這些環(huán)境中的編譯時(shí)間。

圖 1 。 具有不同選項(xiàng)的 FRR 構(gòu)建時(shí)間

總結(jié)

在本文中，我討論了 DPU 應(yīng)用程序的幾個(gè)開發(fā)環(huán)境：

BlueField DPU

x86 服務(wù)器上的 DOCA 開發(fā)容器

AWS Graviton 計(jì)算實(shí)例

你可以直接在 DPU 上對您的應(yīng)用程序進(jìn)行原型設(shè)計(jì)，在 x86 DOCA 開發(fā)容器中進(jìn)行開發(fā)實(shí)踐，然后用 DOCA 獲取一個(gè) AWS Graviton 實(shí)例，使其高速運(yùn)行！