使用 NVIDIA BlueField DPU 和 DPDK 开发应用程序-新利18国际娱乐

数据中心转型

本文引用地址：http://www.eepw.com.cn/article/202205/433848.htm

NVIDIA BlueField DPU （数据处理器）可用于网络功能加速。这种网络卸载可以用 DPDK ,也可以用 NVIDIA DOCA 软件框架。

在本系列中，我构建了一个应用并用两种方式进行了卸载：DPDK 和 NVIDIA DOCA SDK 。我将每个步骤记录为一个单独的代码补丁，并在每个系列中提供完整的步骤。这部分将向您展示如何用 DPDK 编程 BlueField DPU 。

用例

首先，我需要一个简单但有意义的用例来在 DPU 上部署应用程序。我选择了基于策略的路由（ PBR ）来根据第 3 层和第 4 层数据包属性将流量引导到不同的网关，覆盖（或补充） X86 主机选择的网关。现实世界中有各种原因需要这样做，包括以下示例：

· 将选定主机流量发送到外部防火墙以进行额外审核

· 增强 Anycast 服务器的负载平衡

· 应用 QoS

图 1 . 使用 PBR 将流量从主机引导到两个网关之一

我在 DPU （BF2-ARM）上使用 PBR 将流量从主机（ server1-x86 ）引导到两个网关 [leaf2, leaf3] 之一。叶交换机随后将流量转发给其本地连接的选播服务提供商 [server2, server3] 。

构建应用程序

第一个问题：我是写一个全新的应用程序，还是卸载一个现有的应用程序？

我决定卸载我最喜欢的开源路由软件栈 FRRouting （ FRR ）的 PBR 功能。这使我能够扩展现有的代码库，并与现有的 sample apps 形成很好的对比。FRR 有一个支持多种数据平面插件的框架，可以轻松用 DPDK 和 DOCA 实现新的数据平面插件并集成到 FRR 。

图 2 . DPDK 和 DOCA 插件可以很容易地添加到 FRR中

DPU 应用程序原型

在本节中，我将介绍创建具有 DPU 硬件加速功能的应用程序所需的准备工作。

DPU 硬件

我有一个 x86 服务器并在上面安装了一块 BlueFied-2 DPU , 该 DPU 有两个 25G 上行链路和一个带有 8GB 内存的 ARM 处理器。有关硬件安装的更多信息，请参阅 DOCA SDK 文档。您也可以使用 DPU PocKit 来构建和引导你的系统环境.

我安装了 BlueField 启动流文件（ BFB ），它为 DPU 提供了 Ubuntu 操作系统映像，并附带了 DOCA-1.2 和 DPDK-20.11.3 的库。

图 3 . Netdev Representors

使用 SR-IOV ，我在主机上为两个虚拟机创建了两个虚拟函数（ VF ）接口。

主机上的 PF 和 VF 分别映射到 DPU ARM 上的以下 netdev representors 。

表 1 .主机上 PF 和 VF 的映射

使用 DPDK testpmd 应用程序进行原型设计

首先，我使用 DPDK 的 testpmd 进行了我的用例的原型化设计，它位于 DPU 的 / opt / mellanox / 目录下。

包括 testpmd 在内的任何 DPDK 应用程序都必须设置 hugepages 。

（可选）保留配置，使其在 DPU 重新启动后仍然有效。

启动 testpmd 。

Testpmd 会消耗比较多的内存，默认情况下会分配 3.5 GB 。由于我不需要在 CPU 中处理数据流量，我把 total-mem 的值设定为 200M ，其中 total-mem = total-num-mbufs * mbuf-size （默认 mbuf-size 为 2048 字节）。我还使用了 flow-isolation 模式，因为我必须将 ARP 数据包发送到 DPU 上的内核网络堆栈来解析 PBR 的下一跳）。初始化完成后，-i选项使得 testpmd 进入交互式 shell 。

作为 testpmd 完成 rte_eal 初始化的一部分, mlx5_pci 设备被探测并成为可以被访问的 DPDK 端口。

您在这里看到的 DPDK 端口对应 PF / VF representor 和两个上行链路。

表 2 . DPDK 端口映射

流创建

接下来，通过定义 ingress port 、源 IP 、目标 IP 、协议和端口，我用 rte_flow 下发了PBR规则。除此之外，我还定义了对匹配数据包采取的 ACTION 。源 MAC 和目标 MAC 被重写， TTL 被递减，出口端口被设置为物理上行链路 p0 。

这条 PBR 规则从 VM1接收 DNS 流量，并将其发送到特定的 GW （ leaf2, server2 ）。我还增加了一个计数器以便故障定位。

DPU 卸载可以工作在 Switch ( FDB )模式，也可以工作在 NIC 模式。在这个用例中，经过几次数据包修改后，我需要将流量从 X86 主机重定向到 25G 上行链路。所以从概念上讲，这里使用了 Switch ( FDB ) 模式，因此需要设置 rte_flow 的 transfer 属性。

流程验证

我从 VM1 发送了一些流量，看看它是否与我用 testpmd 创建的 flow 是否匹配，可以通过执行 query 命令来查看。

结果是匹配的，在 leaf2/server2 上可以看到这些流量且具有修改后的数据包头。因为被操作的流量是 DNS ，所以为了测试流量，我从 VM1 发送 DNS 请求。为了控制流量速率和其他数据包字段，我使用 mz 来生成测试流量。

另一个健全性检查是查看此流是否真的被卸载。有两种方法可以做到这一点：

· 在 Arm CPU 上使用 tcpdump 以确保内核不接收此类数据包。

· 检查硬件 eSwitch 是否有对应的流规则。

mlx_steering_dump 允许您查看硬件上已经下发成功的流规则。使用 git 下载并安装该工具。

使用 mlx_steering_dump_parser.py 脚本验证硬件中下发的流规则。

此命令打印出 testpmd 应用程序下发的所有流规则。我们可以看到硬件上设置的外部头匹配信息和前面RTE_FLOW定义的匹配 [SIP = 172.20.0.8 ， DIP = 172.30.0.8 ， IP proto = UDP ， UDP dport = 53] 是一致的。作为打印输出的一部分，流量计数器的值也被读取并被重置。

原型设计，作为应用程序设计思维过程的最后一步现在已经完成。我现在知道我可以在 DPDK 中建立一个 PBR 规则，把它安装在硬件中并对我们感兴趣的数据报文进行修改。现在在下一节中添加 DPDK 数据平面。

构建 DPDK 数据平面插件

在本节中，我将通过向 Zebra 添加一个 DPDK 数据平面插件，介绍 DPU 对 PBR进行硬件加速的步骤。我将这些步骤分解为单独的代码提交，整个补丁集以 reference 的形式提供。