第一步

第二步

去喝杯咖啡…

第三步

您在說明書中常常看到“去喝杯咖啡”嗎?作為一名開發人員，我很早就發現這種令人生厭的俏皮話是我生活中的禍根。無論持續時間長短，進程切換(Context Switches)在應用程序開發周期中都是一項高昂的成本。在所有需要您離開的步驟中，等待應用程序編譯是最難擺脫的。

當我們進入 NVIDIA BlueField DPU 應用程序開發的新世界，有效地設置構建步驟非常重要，以便您能夠無縫地編碼→編譯→單元測試。在本文中，我介紹了 DPU 編譯應用程序的不同方法。

DOCA 數據平面插件的 FRR

(Free Range Routing)

在 DPU 應用程序開發系列文章中，我談到了在 FRR 中創建 DOCA 數據平面插件以用于卸載策略。FRR 的代碼行數接近 100 萬行( 789678 SLOC )，這使得它成為衡量構建時間的絕佳候選。

直接在 BlueField DPU 上開發

DPU 具有 Arm64 架構，一種快速啟動 DPU 應用程序的方法就是直接在 DPU 上開發。本測試使用具有 8G RAM 和 8 個 A72 CPU 內核的 NVIDIA BlueField2 DPU 。

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

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

FRR 需要一個不斷發展的先決條件列表，這些先決條件列舉在FRR 社區文檔中。安裝了這些依賴項后，我將 FRR 配置為包括 DPDK 和 DOCA 數據平面插件。

當我使用 DPU 作為我的開發環境時，我構建并安裝了 FRR 二進制文件：

以下是構建時間的表現。我用多種方法來衡量：

• 使用make -j12 all 和 make install構建和安裝二進制文件的時候

• 使用dpkg-buildpackage –j12 –uc –us將它們組裝成 Debian 軟件包來構建相同二進制文件的時候

第一種方法用于編碼和單元測試。第二種生成 deb 的方法需要與其他外部開發環境上的構建時間進行比較。

表 1 . DPU Arm 構建時間

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

使用 DPU 作為開發環境有一些明顯的優勢：

• 您可以在不離開工作區的情況下進行編碼、構建和安裝，然后進行單元測試。

• 您可以針對增量代碼更改來優化構建。

與完整構建（Complete make）相比，最后一個選擇通常可以大幅縮短構建時間。例如，我在 FRR 中修改了 DOCA 數據平面代碼，并重建的結果如下：

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

在 x86 服務器上開發

我的 BlueField-2 DPU 由一臺 x86-64 Ubuntu 20.04 服務器托管，我將這臺服務器用于我的開發環境。

在本例中，構建機器是 x86 ，應用程序將運行的主機是 DPU-Arm64 。有幾種方法可以做到這一點：

• 在 x86 構建機器上使用 Arm 仿真。提供的 DOCA 開發容器作為 DOCA 軟件包的一部分。

• 使用交叉編譯工具鏈。

在這個測試中，我使用了第一個選項，因為它是最簡單的。第二個選項可以提供不同的性能，但創建該工具鏈有其挑戰。

我在x86 服務器上下載并加載了bfb_builder_doca_ubuntu_20.04容器，并啟動了它。

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

我在容器中設置了工作區和 FRR 先決條件，與前面的選項相同。

我可以在這個 DOCA 容器中構建我的應用程序，但我無法對其進行測試。因此，必須將 FRR 二進制文件構建并打包到 deb 中，然后將其復制到 BlueField DPU 進行測試。我設置了 FRR Debian 規則，以匹配前面選項中使用的 FRR 構建配置，并生成了軟件包：

表 2 顯示了構建時間與以前方法的比較：

表 2 . DPU Arm 和 X86 構建時間

構建時間的大幅增加讓我感到驚訝，因為我有一臺充足 x86 資源的服務器，而且沒有 Docker 限制。因此，將 CPU 和 RAM 用于解決問題似乎并不總是有幫助的!這種性能下降是因為跨體系結構造成的，正如您在下一個選項中看到的那樣。

在 AWS Graviton 實例中開發

接下來，我嘗試在 Arm 上構建我的應用程序，但這次是在性能更大的外部服務器上。為此，我使用了 Amazon EC2 Graviton 實例，其規格與我的 x86 服務器相當。

• Arm 64 arch , Ubuntu 20.04 操作系統

• 128G 內存

• 32 vCPU

為了在這個實例中設置 DOCA 和 DPDK 庫，我安裝了 DOCA SDK repo meta 包。

克隆和構建 FRR Debian 軟件包的其余步驟與前面的選項相同。

表 3 顯示了構建在 AWS Arm 實例上的運行情況：

表 3 . DPU Arm 、X86 和 AWS Arm 的構建時間

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

圖 1 顯示了這些環境中的編譯時間。

圖 1 . 具有不同選項的 FRR 構建時間

總結

在本文中，我討論了 DPU 應用程序的幾個開發環境：

• BlueField DPU

• x86 服務器上的 DOCA 開發容器

• AWS Graviton 計算實例

你可以直接在 DPU 上對您的應用程序進行原型設計，在 x86 DOCA 開發容器中進行開發實踐，然后用 DOCA 獲取一個 AWS Graviton 實例，使其高速運行！

原文標題：為 NVIDIA BlueField DPU 應用程序選擇開發環境

文章出處：【微信公眾號：NVIDIA英偉達企業解決方案】歡迎添加關注!文章轉載請注明出處。

審核編輯：湯梓紅