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 实例，使其高速运行！
探究寄存机的电路结构以及惯常用法
proteus使用入门教程
一加5什么时候上市？一加5即将发布：一加5国产新标杆遇上7年磨一剑的小米6，等待还是购买呢？
智能型农药残留检测仪是什么
小米靠低价拿下印度手机市场，击败三星占据28%市场份额
DPU编译应用程序的不同方法
iPhone新款5G手机曝光，搭载苹果A14但是没有刘海
一文了解LoRa与LoRaWAN差异及市场前景
智能电缆井盖您见过吗？
让两个ESP8266之间建立无线通信
【技术分享】带你认识什么是PRU
车载配件
移动发布《5G终端白皮书》 确保2020年全面成熟商用
极氪001FR发布：搭载卫星通信技术 定价或超百万
小米6和OPPOR11全面对比评测：你是买性价比神机的小米6还是买拍照神器OPPO R11？
看看2018年12月有物联网领域哪些重大事件
思必驰入选“2023年度江苏省创新联合体建设试点”名单
高交会上机器人表现亮眼 无人驾驶黑科技各怀绝技
示波器如何直连电脑进行波形读取？
谷歌125亿美元收购摩托罗拉移动
当我们进入 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 实例，使其高速运行！
探究寄存机的电路结构以及惯常用法
proteus使用入门教程
一加5什么时候上市？一加5即将发布：一加5国产新标杆遇上7年磨一剑的小米6，等待还是购买呢？
智能型农药残留检测仪是什么
小米靠低价拿下印度手机市场，击败三星占据28%市场份额
DPU编译应用程序的不同方法
iPhone新款5G手机曝光，搭载苹果A14但是没有刘海
一文了解LoRa与LoRaWAN差异及市场前景
智能电缆井盖您见过吗？
让两个ESP8266之间建立无线通信
【技术分享】带你认识什么是PRU
车载配件
移动发布《5G终端白皮书》 确保2020年全面成熟商用
极氪001FR发布：搭载卫星通信技术 定价或超百万
小米6和OPPOR11全面对比评测：你是买性价比神机的小米6还是买拍照神器OPPO R11？
看看2018年12月有物联网领域哪些重大事件
思必驰入选“2023年度江苏省创新联合体建设试点”名单
高交会上机器人表现亮眼 无人驾驶黑科技各怀绝技
示波器如何直连电脑进行波形读取？
谷歌125亿美元收购摩托罗拉移动