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 的构建时间

这是一个明显的赢家，不需要咖啡。

图 1 显示了这些环境中的编译时间。

 

图 1 。具有不同选项的 FRR 构建时间

　　总结

　　在本文中，我讨论了 DPU 应用程序的几个开发环境：

　　BlueField 增值税

　　x86 服务器上的 DOCA 开发容器

　　AWS 引力计算实例

　　你可以直接在 DPU 上制作应用程序原型，在 x86 DOCA 开发容器中进行开发实验，然后用 DOCA 抓取一个 AWS Graviton 实例，使其进入 hyperspeed ！

　　关于作者

　　Anuradha Karuppiah 是 NVIDIA 网络的首席软件工程师。 Anuradha 使用 FRR （自由范围路由软件套件）设计和实现 EVPN 解决方案。

　　审核编辑：郭婷