您在說明書中常常看到“去喝杯咖啡”嗎?作為一名開發(fā)人員,我很早就發(fā)現(xiàn)這種令人生厭的俏皮話是我生活中的禍根。無論持續(xù)時間長短,進(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)建時間的絕佳候選。
直接在 BlueField DPU 上開發(fā)
DPU 具有 Arm64 架構(gòu),一種快速啟動 DPU 應(yīng)用程序的方法就是直接在 DPU 上開發(fā)。本測試使用具有 8G RAM 和 8 個 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 需要一個不斷發(fā)展的先決條件列表,這些先決條件列舉在 FRR 社區(qū)文檔中。安裝了這些依賴項(xiàng)后,我將 FRR 配置為包括 DPDK 和 DOCA 數(shù)據(jù)平面插件。
當(dāng)我使用 DPU 作為我的開發(fā)環(huán)境時,我構(gòu)建并安裝了 FRR 二進(jìn)制文件:
以下是構(gòu)建時間的表現(xiàn)。我用多種方法來衡量:
使用 make -j12 all 和 make install 構(gòu)建和安裝二進(jìn)制文件的時候
使用 dpkg-buildpackage –j12 –uc –us 將它們組裝成 Debian 軟件包來構(gòu)建相同二進(jìn)制文件的時候
第一種方法用于編碼和單元測試。第二種生成 deb 的方法需要與其他外部開發(fā)環(huán)境上的構(gòu)建時間進(jìn)行比較。
表 1 。 DPU Arm 構(gòu)建時間
時間上的差異是意料之中的。生成一個包需要幾個額外的步驟。
使用 DPU 作為開發(fā)環(huán)境有一些明顯的優(yōu)勢:
您可以在不離開工作區(qū)的情況下進(jìn)行編碼、構(gòu)建和安裝,然后進(jìn)行單元測試。
您可以針對增量代碼更改來優(yōu)化構(gòu)建。
與完整構(gòu)建(Complete make)相比,最后一個選擇通常可以大幅縮短構(gòu)建時間。例如,我在 FRR 中修改了 DOCA 數(shù)據(jù)平面代碼,并重建的結(jié)果如下:
雖然這可能會讓事情變得更簡單,但它需要為每個開發(fā)人員無限期的保留 DPU ,僅用于應(yīng)用程序開發(fā)或維護(hù)。您的開發(fā)環(huán)境可能還需要更多的內(nèi)存和性能,因此長期來看,這是一個不太可行的選擇。
在 x86 服務(wù)器上開發(fā)
我的 BlueField-2 DPU 由一臺 x86-64 Ubuntu 20.04 服務(wù)器托管,我將這臺服務(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 軟件包的一部分。
使用交叉編譯工具鏈。
在這個測試中,我使用了第一個選項(xiàng),因?yàn)樗亲詈唵蔚摹5诙€選項(xiàng)可以提供不同的性能,但創(chuàng)建該工具鏈有其挑戰(zhàn)。
我在x86 服務(wù)器上下載并加載了 bfb_builder_doca_ubuntu_20.04 容器,并啟動了它。
DOCA 和 DPDK 庫預(yù)先安裝在這個容器中,我只需要將它們添加到 PKG_CONFIG 路徑。
我在容器中設(shè)置了工作區(qū)和 FRR 先決條件,與前面的選項(xiàng)相同。
我可以在這個 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)建時間與以前方法的比較:
表 2 。 DPU Arm 和 X86 構(gòu)建時間
構(gòu)建時間的大幅增加讓我感到驚訝,因?yàn)槲矣幸慌_充足 x86 資源的服務(wù)器,而且沒有 Docker 限制。因此,將 CPU 和 RAM 用于解決問題似乎并不總是有幫助的!這種性能下降是因?yàn)榭珞w系結(jié)構(gòu)造成的,正如您在下一個選項(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
為了在這個實(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)建時間
這是一個明顯的贏家,不需要咖啡。
圖 1 顯示了這些環(huán)境中的編譯時間。
圖 1 。 具有不同選項(xiàng)的 FRR 構(gòu)建時間
總結(jié)
在本文中,我討論了 DPU 應(yīng)用程序的幾個開發(fā)環(huán)境:
BlueField DPU
x86 服務(wù)器上的 DOCA 開發(fā)容器
AWS Graviton 計算實(shí)例
你可以直接在 DPU 上對您的應(yīng)用程序進(jìn)行原型設(shè)計,在 x86 DOCA 開發(fā)容器中進(jìn)行開發(fā)實(shí)踐,然后用 DOCA 獲取一個 AWS Graviton 實(shí)例,使其高速運(yùn)行!
-
DPU
+關(guān)注
關(guān)注
0文章
354瀏覽量
24133 -
應(yīng)用程序
+關(guān)注
關(guān)注
37文章
3245瀏覽量
57614 -
編譯
+關(guān)注
關(guān)注
0文章
654瀏覽量
32813
發(fā)布評論請先 登錄
相關(guān)推薦
評論