为 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 的硬件加速：软件视角