NVIDIA BlueField DPU编译应用程序的不同方法

 

　　第一步

　　第二步

　　去喝杯咖啡…

　　第三步

　　您在说明书中常常看到“去喝杯咖啡”吗?作为一名开发人员，我很早就发现这种令人生厌的俏皮话是我生活中的祸根。无论持续时间长短，进程切换(Context Switches)在应用程序开发周期中都是一项高昂的成本。在所有需要您离开的步骤中，等待应用程序编译是最难摆脱的。

　　当我们进入 NVIDIA BlueField DPU 应用程序开发的新世界，有效地设置构建步骤非常重要，以便您能够无缝地编码→编译→单元测试。在本文中，我介绍了 DPU 编译应用程序的不同方法。

　　DOCA 数据平面插件的 FRR

　　(Free Range Routing)

　　在 DPU 应用程序开发系列文章中，我谈到了在 FRR 中创建 DOCA 数据平面插件以用于卸载策略。FRR 的代码行数接近 100 万行( 789678 SLOC )，这使得它成为衡量构建时间的绝佳候选。

　　直接在 BlueField DPU 上开发

　　DPU 具有 Arm64 架构，一种快速启动 DPU 应用程序的方法就是直接在 DPU 上开发。本测试使用具有 8G RAM 和 8 个 A72 CPU 内核的 NVIDIA BlueField2 DPU 。

 

我安装了 BlueField 引导文件（ BFB ），它为 DPU 提供 Ubuntu 20.04.3 操作系统映像。它还包括 DOCA 1.2 和 DPDK 20.11.3 库。为了使用 DOCA 库构建应用程序，我将 DPDK pkgconfig 位置添加到 PKG_CONFIG 路径。

 

 

接下来，我通过克隆 FRR 在 DPU 上设置了我的代码工作区，并切换到 DOCA 数据平面插件。

 

 

FRR 需要一个不断发展的先决条件列表，这些先决条件列举在 FRR 社区文档中。安装了这些依赖项后，我将 FRR 配置为包括 DPDK 和 DOCA 数据平面插件。

 

 

当我使用 DPU 作为我的开发环境时，我构建并安装了 FRR 二进制文件：

 

 

以下是构建时间的表现。我用多种方法来衡量：

 

• 使用 make -j12 all 和 make install 构建和安装二进制文件的时候

• 使用 dpkg-buildpackage –j12 –uc –us 将它们组装成 Debian 软件包来构建相同二进制文件的时候

 

第一种方法用于编码和单元测试。第二种生成 deb 的方法需要与其他外部开发环境上的构建时间进行比较。

表 1 . DPU Arm 构建时间

 

时间上的差异是意料之中的。生成一个包需要几个额外的步骤。

 

使用 DPU 作为开发环境有一些明显的优势：

 

• 您可以在不离开工作区的情况下进行编码、构建和安装，然后进行单元测试。

• 您可以针对增量代码更改来优化构建。

 

与完整构建（Complete make）相比，最后一个选择通常可以大幅缩短构建时间。例如，我在 FRR 中修改了 DOCA 数据平面代码，并重建的结果如下：

 

 

　　虽然这可能会让事情变得更简单，但它需要为每个开发人员无限期的保留 DPU ，仅用于应用程序开发或维护。您的开发环境可能还需要更多的内存和性能，因此长期来看，这是一个不太可行的选择。

　　在 x86 服务器上开发

　　我的 BlueField-2 DPU 由一台 x86-64 Ubuntu 20.04 服务器托管，我将这台服务器用于我的开发环境。

 

在本例中，构建机器是 x86 ，应用程序将运行的主机是 DPU-Arm64 。有几种方法可以做到这一点：

 

• 在 x86 构建机器上使用 Arm 仿真。 提供的 DOCA 开发容器 作为 DOCA 软件包的一部分。

• 使用交叉编译工具链。

 

在这个测试中，我使用了第一个选项，因为它是最简单的。第二个选项可以提供不同的性能，但创建该工具链有其挑战。

 

我在x86 服务器上下载并加载了 bfb_builder_doca_ubuntu_20.04 容器，并启动了它。

 

 

DOCA 和 DPDK 库预先安装在这个容器中，我只需要将它们添加到 PKG_CONFIG 路径。

 

 

我在容器中设置了工作区和 FRR 先决条件，与前面的选项相同。

 

 

我可以在这个 DOCA 容器中构建我的应用程序，但我无法对其进行测试。因此，必须将 FRR 二进制文件构建并打包到 deb 中，然后将其复制到 BlueField DPU 进行测试。我设置了 FRR Debian 规则，以匹配前面选项中使用的 FRR 构建配置，并生成了软件包：

 

 

表 2 显示了构建时间与以前方法的比较：

 

表 2 . DPU Arm 和 X86 构建时间

 

　　构建时间的大幅增加让我感到惊讶，因为我有一台充足 x86 资源的服务器，而且没有 Docker 限制。因此，将 CPU 和 RAM 用于解决问题似乎并不总是有帮助的!这种性能下降是因为跨体系结构造成的，正如您在下一个选项中看到的那样。

　　在 AWS Graviton 实例中开发

　　接下来，我尝试在 Arm 上构建我的应用程序，但这次是在性能更大的外部服务器上。为此，我使用了 Amazon EC2 Graviton 实例，其规格与我的 x86 服务器相当。

 

• Arm 64 arch , Ubuntu 20.04 操作系统

• 128G 内存

• 32 vCPU

   

 

为了在这个实例中设置 DOCA 和 DPDK 库，我安装了 DOCA SDK repo meta 包 。

 

 

克隆和构建 FRR Debian 软件包的其余步骤与前面的选项相同。

 

表 3 显示了构建在 AWS Arm 实例上的运行情况：

 

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

 

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

 

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

 

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

　　总结

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

 

• BlueField DPU

• x86 服务器上的 DOCA 开发容器

• AWS Graviton 计算实例

 

你可以直接在 DPU 上对您的应用程序进行原型设计，在 x86 DOCA 开发容器中进行开发实践，然后用 DOCA 获取一个 AWS Graviton 实例，使其高速运行！

　　原文标题：为 NVIDIA BlueField DPU 应用程序选择开发环境

　　文章出处：【微信公众号：NVIDIA英伟达企业解决方案】欢迎添加关注!文章转载请注明出处。

　　审核编辑：汤梓红