NVIDIA BlueField DPU应用程序的不同编译方法-电子发烧友网

随着我们进入 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 显示了构建时间与以前方法的比较。

表 2 。 DPU Arm 和 X86 构建时间

构建时间的巨大飞跃让我感到惊讶，因为我有一台库存充足的 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 实例上的运行情况。

表 3 。 DPU Arm 、 X86 和 AWS Arm 的构建时间