為 NVIDIA BlueField DPU 應用程序選擇開發環境

Step-A

Step-B

去喝杯咖啡…

Step-C

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

隨著我們進入 NVIDIA BlueField DPU 應用程序開發的新世界，高效地設置構建步驟非常重要，以便您能夠無縫地{code => compile => unit-test}。在本文中，我介紹了為 DPU 編譯應用程序的不同方法。

DOCA 數據平面插件的自由范圍路由

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

直接在 BlueField DPU 上開發

DPU 具有 Arm64 體系結構，一種快速啟動 DPU 應用程序的方法是直接在 DPU 上開發。本測試使用的是 NVIDIA BlueField2 ，帶有 8G RAM 和 8xCortex-A72 CPU 。

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

root@dpu-arm:~# export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/mellanox/dpdk/lib/aarch64-linux-gnu/pkgconfig 

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

root@dpu-arm:~/code# git clone  https://github.com/AnuradhaKaruppiah/frr.git  
root@dpu-arm:~/code# cd frr 
root@dpu-arm:~/code/frr# git checkout dp-doca 

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

root@dpu-arm:~/code/frr# ./bootstrap.sh 

root@dpu-arm:~/code/frr# ./configure --build=aarch64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/lib/aarch64-linux-gnu --libexecdir=\${prefix}/lib/aarch64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking --enable-exampledir=/usr/share/doc/frr/examples/ --localstatedir=/var/run/frr --sbindir=/usr/lib/frr --sysconfdir=/etc/frr --with-vtysh-pager=/usr/bin/pager --libdir=/usr/lib/aarch64-linux-gnu/frr --with-moduledir=/usr/lib/aarch64-linux-gnu/frr/modules "LIBTOOLFLAGS=-rpath /usr/lib/aarch64-linux-gnu/frr" --disable-dependency-tracking --disable-dev-build --enable-systemd=yes --enable-rpki --with-libpam --enable-doc --enable-doc-html --enable-snmp --enable-fpm --disable-zeromq --enable-ospfapi --disable-bgp-vnc --enable-multipath=128 --enable-user=root --enable-group=root --enable-vty-group=root --enable-configfile-mask=0640 --enable-logfile-mask=0640 --disable-address-sanitizer --enable-cumulus=yes --enable-datacenter=yes --enable-bfdd=no --enable-sharpd=yes --enable-dp-doca=yes --enable-dp-dpdk=yes 

因為我用 DPU 作為 my 開發環境Roment ，我構建并安裝了 FRR 二進制文件：

root@dpu-arm:~/code# make –j12 all; make install 

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

• 是時候使用make -j12 all和make install構建和安裝二進制文件了
• 是時候構建相同的二進制文件了，但也可以使用dpkg-buildpackage –j12 –uc –us將它們組裝到 Debian 軟件包中

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

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

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

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

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

root@dpu-arm:~/code/frr# time make –j12 

>>>>>>>>>>>>> snipped make output >>>>>>>>>>>> 

real 0m3.119s 

user 0m2.794s 

sys 0m0.479s 

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

在 x86 服務器上開發

我的 Bluefield2 DPU 由一臺 x86-64 Ubuntu 20.04 服務器托管，我在開發環境中使用了這臺服務器。

root@server1-x86:~# lscpu |grep "CPU(s):\|Model name" 

CPU(s): 32 

Model name: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz 

root@server1-x86:~# grep MemTotal /proc/meminfo 

MemTotal: 131906300 kB 

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

• 在 x86 構建機器上使用 Arm 仿真。 A . DOCA 開發容器 作為 DOCA 軟件包的一部分提供。
• 使用交叉編譯工具鏈。

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

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

root@server1-x86:~# sudo docker load -i bfb_builder_doca_ubuntu_20.04-mlnx-5.4.tar 
root@server1-x86:~# docker run -v ~/code:/code --privileged -it -e container=dock 
er doca_v1.11_bluefield_os_ubuntu_20.04-mlnx-5.4:latest 

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

root@86b87b0ab0c2:/code # export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/mellanox/dpdk/lib/aarch64-linux-gnu/pkgconfig 

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

root@86b87b0ab0c2:/code # git clone  https://github.com/AnuradhaKaruppiah/frr.git  
root@86b87b0ab0c2:/code # cd frr 
root@86b87b0ab0c2:/code/frr # git checkout dp-doca 

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

root@86b87b0ab0c2:/code/frr # dpkg-buildpackage –j12 –uc -us 

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

構建時間的巨大飛躍讓我感到驚訝，因為我有一臺庫存充足的 x86 服務器，而且沒有 Docker 限制。因此，將 CPU 和 RAM 扔到一個問題上似乎并不總是有幫助！這種性能下降是因為跨體系結構，正如您在下一個選項中看到的那樣。

在 AWS 引力子實例中開發

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

• Arm64 arch ， Ubuntu 20.04 操作系統
• 128G 內存
• 32 伏 CPU

root@ip-172-31-28-243:~# lscpu |grep "CPU(s):\|Model name" 
CPU(s): 32 
Model name: Neoverse-N1 
root@ip-172-31-28-243:~# grep MemTotal /proc/meminfo 
MemTotal: 129051172 kB 

為了在本例中設置 DOCA 和 DPDK 庫，我安裝了 DOCA SDK 回購元包 .

root@ip-172-31-28-243:~# dpkg -i doca-repo-aarch64-ubuntu2004-local_1.1.1-1.5.4.2.4.1.3.bf.3.7.1.11866_arm64.deb 
root@ip-172-31-28-243:~#  apt update 
root@ip-172-31-28-243:~# apt install doca-sdk 

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

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

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

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

總結

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

• BlueField 增值稅
• x86 服務器上的 DOCA 開發容器
• AWS 引力計算實例

你可以直接在 DPU 上制作應用程序原型，在 x86 DOCA 開發容器中進行開發實驗，然后用 DOCA 抓取一個 AWS Graviton 實例，使其進入 hyperspeed ！

有關更多信息，請參閱以下參考資料：

• NVIDIA 推出 BlueField DPU 作為 DOCA 1.2 的零信任安全平臺
• 用 NVIDIA DOCA 1.2 構建零信任安全基礎
• BlueField DPU 的 NVIDIA DOCA 簡介 DLI 課程
• 基于 DPU 的硬件加速：軟件視角

?