主要负责人¶
Dmitrii Shcherbakov (lp: ~dmitriis, oftc || libera: dmitriis)
Frode Nordahl (lp: ~fnordahl, oftc || libera: fnordahl)
Off-path SmartNIC DPU 端口绑定与 OVN¶
https://blueprints.launchpad.net/neutron/+spec/off-path-smartnic-dpu-port-binding-with-ovn
Off-path SmartNIC DPU 引入了一种架构变更，负责 NIC 交换机配置和 representor 接口插拔的网络代理运行在独立的 SoC 上，该 SoC 拥有自己的 CPU、内存和独立的操作系统内核。这种副作用是 hypervisor 主机名不再与 ovs-vswitchd 和 OVN [3] 代理所见的 SmartNIC DPU 主机名不匹配，而现有的端口绑定代码依赖于此。本规范的目标是引入必要的变更，以扩展现有的硬件卸载代码，以应对主机名不匹配和相关的设计挑战，同时重用其余代码。为此，引入了具有唯一序列号的 PCIe 加卡跟踪，以便可以用来确定负责特定 VF 的 SmartNIC DPU 的正确主机名。此外，建议在端口更新期间在“binding:profile”中传递更多信息，以方便 representor 端口的插拔。
Nova 规范：https://review.opendev.org/c/openstack/nova-specs/+/787458
问题描述¶
术语¶
数据处理单元 (DPU) - 一种嵌入式系统，包括 CPU、NIC 以及可能在其板载的其他组件，通过一些 I/O 互连（例如 PCIe）与主板集成；
Off-path SmartNIC DPU 架构 [1] [2] - 一种 NIC 核心负责编程 NIC 交换机的架构，并在 NIC 交换机中编程的规则足以做出关于数据包传递位置的决策时被绕过。通常，NIC 核心仅参与“慢路径”的数据包转发，而“快路径”则由硬件（如 ASIC）处理；
On-path SmartNIC DPU 架构 [1] [2] - 一种 NIC 核心参与处理通过 NIC 的每个数据包的架构。换句话说，NIC 核心始终处于所有数据包的“快路径”上；
NIC 交换机（或 eSwitch）- 存在于各种类型的 NIC（SR-IOV 兼容 NIC、Off-path SmartNIC）中的可编程嵌入式交换机。通常依赖于 ASIC 进行数据包处理；
switchdev [4] - 内核驱动程序模型，用于交换设备，它将转发（数据）平面从内核卸载。
Representor 端口 [5] - switchdev 模型中引入的概念，它模拟了代表交换机端口的 netdev。这适用于 NIC 交换机端口（可以是物理上行端口、PF 或 VF）；
devlink [6] - 内核 API，用于暴露与任何设备类不直接相关的设备信息和资源，例如芯片范围/交换机 ASIC 范围的配置；
PCI/PCIe Vital Product Data (VPD) - 由 PCI(e) 端点暴露的标准功能，其中包含各种信息，包括卡的唯一序列号（只读、持久、工厂生成），该序列号由其暴露的所有功能共享。存在于 PCI 本地总线 2.1+ 和 PCIe 4.0+ 规范中。
详细概述¶
相关的 Nova 规范 [7] 是跨项目工作不可或缺的一部分，其问题描述被假定为本规范的一部分。
还有相关的 OVS [8] 和 OVN 本身 [9] [10] 的变更，为了便于在 Neutron 中实现本规范，这些变更是必要的。上游 OVN 讨论的结果是，将引入一个单独的 ovn-vif [11] 组件，并且相应的变更 [10] 正在撰写本文时处于审查过程的后期阶段。支持其他 ML2 机制驱动程序是可能的，但我们希望首先定位 OVN，并将其他 ML2 驱动程序排除在 Yoga 周期之外。
在 Off-path SmartNIC DPU 的上下文中，需要解决的主要问题是
SmartNIC DPU 主机名选择，以便为 representor 端口插拔选择正确的主机。这对应于在 OVN 术语中选择正确的底盘（传输节点）；
VF representor 选择，对应于 hypervisor 主机侧 Nova 选择的 VF 和与其关联的 PF。
一些实际挑战如下
如果使用 PCIe 访问 SmartNIC DPU 主机的 NIC，hypervisor 主机和 SmartNIC DPU 主机所看到的 PCI 地址不同，因为它们拥有自己的根复用器并看到隔离的 PCIe 拓扑（同时与相同的 NIC 通信）。因此，从 SmartNIC DPU 主机侧看到的 PCI 地址在 hypervisor 主机侧没有意义；
NIC 交换机未暴露给 hypervisor 主机侧的 PF。同时，PF representor 编号与 SmartNIC DPU 主机侧的特定 NIC 交换机（控制器编号）相关联。在一般情况下，每个 SmartNIC DPU 主机可能有多个控制器，因此仅从主机侧传递 PF 逻辑编号不足以识别传输节点侧的 PF representor；
通过 devlink 端口属性看到的 VF 逻辑编号取决于 hypervisor 主机上的设备驱动程序实现，并不总是与 SmartNIC DPU 主机通过 NIC 交换机看到的 VF 逻辑编号匹配。可以根据 PCI SIG SR-IOV 规范管理的 VF PCI 地址分配过程，检索基于 PF 的 VF 逻辑编号；
在端口绑定期间，OVN 机制驱动程序需要处理当前未处理的 vnic 类型 VNIC_REMOTE_MANAGED。
下图说明了在本文档上下文中起作用的各种组件
┌────────────────────────────────────┐
│ Hypervisor │ LoM Ports
│ ┌───────────┐ ┌───────────┐ │ (on-board,
│ │ Instance │ │ Nova │ ├──┐ optional)
│ │ (QEMU) │ │ Compute │ │ ├─────────┐
│ │ │ │ │ ├──┘ │
│ └───────────┘ └───────────┘ │ │
│ │ │
└────────────────┬─┬───────┬─┬──┬────┘ │
│ │ │ │ │ │
│ │ │ │ │ Control Traffic │
Instance VF │ │ │ │ │ PF associated │
│ │ │ │ │ with an uplink │
│ │ │ │ │ port or a VF. │
│ │ │ │ │ (used to replace│
│ │ │ │ │ LoM) │
┌────────────────────────────────────┼─┼───────┼─┼──┼─┐ │
│ SmartNIC DPU Board │ │ │ │ │ │ │
│ (transport node) │ │ │ │ │ │ │
│ ┌──────────────┐ Control traffic │ │ │ │ │ │ │
│ │ App. CPU │ via PFs or VFs ┌┴─┴───────┴─┴┐ │ │ │
│ ├──────────────┤ (DC Fabric) │ │ │ │ │
│ │ovn-controller├─────────────────┼─┐ │ │ │ │
│ ├──────────────┤ │ │ │ │ │ │
│ │ovs-vswitchd │ Port │ │NIC Switch │ │ │ │
│ ├──────────────┤ Representors │ │ ASIC │ │ │ │
│ │ br-int ├─────────────────┤ │ │ │ │ │
│ │ ├─────────────────┤ │ │ │ │ │
│ └──────────────┘ │ │ │ │ │ │
│ │ │ │ │ │ │
│ └─┼───┬─┬─────┘ │ │ │
┌─┴──────┐Initial NIC Switch │ │ │ │ │ │
─┤OOB Port│configuration is done via │ │ │uplink │ │ │
└─┬──────┘the OOB port to create │ │ │ │ │ │
│ ports for control traffic. │ │ │ │ │ │
└─────────────────────────────────────┼───┼─┼───────┼─┘ │
│ │ │ │ │
┌──┼───┴─┴───────┼────────┐ │
│ │ │ │ │
│ │ DC Fabric ├────────┼────────┘
│ │ │ │
└──┼─────────────┼────────┘
│ │
│ ┌───┴──────┐
│ │ │
┌───▼──┐ ┌───▼───┐ ┌────▼────┐
│OVN SB│ │Neutron│ │Placement│
└──────┘ │Server │ │ │
└───────┘ └─────────┘
提议的变更¶
识别 SmartNIC DPU 主机和 VF Representor¶
相关的 Nova 规范 [7] 引入了通过 PCIe VPD 收集加卡序列号并将该信息转发到 Neutron 的端口更新，因此可以将其与 SmartNIC DPU 主机侧看到的内容进行匹配。这些序列号是唯一的、只读的，并且在制造时分配（根据 PCI 和 PCIe 规范）。板载序列号可以存储在 OVN SB 数据库中，作为特定 OVN 底盘的 external-id
external_ids:ovn-cms-options='card-serial-number=UNIQUEBOARDSERIAL'
请注意，可以通过其他方式从 SmartNIC DPU 主机侧访问 NIC（例如平台设备或其他 I/O 类型），因此可以通过提取通过 sysfs 的 PCIe VPD 或使用 devlink-info API 并获取 board.serial_number（不依赖于特定的 I/O 互连类型）来查询序列号。但是，这对于 OVN 而言是一个问题，因为 Neutron 在 SmartNIC DPU 侧没有运行任何代理 - 它只需要根据 card-serial-number 查找 chassis，而不管它如何在 SmartNIC DPU 主机上收集。
放置它的责任可以由以下人员承担
部署者将负责配置 ovn-controller 代理，使其负责特定的传输节点；
ovn-controller 本身基于某种默认行为，查找基于 switchdev 兼容设备在 SmartNIC DPU 主机上可用的卡序列号。
无论选择哪种方法来填充此值，Neutron 都能够查找应该处理特定端口更新的 representor 插拔和流编程的 OVN chassis，该端口更新包含卡序列号。
VF 逻辑编号在特定 PF 的上下文中是相关的。反过来，PF 逻辑编号与特定的控制器相关联。由于 NIC 交换机未暴露给 hypervisor 主机，因此它无法确定 SmartNIC DPU 主机可见的控制器逻辑编号，并且虽然 PF 编号可以间接从其 PCI 地址功能编号推断出来，但此信息不足以识别 SmartNIC DPU 主机侧的 PF representor。为了解决这个问题，可以传递 hypervisor 主机看到的 PF MAC 到 SmartNIC DPU 主机。虽然端口 representor 的 MAC 地址与它所代表的端口不同，但可以使用通用的内核 API 来通过其 representer 检索函数的 MAC 地址（从内核 5.9 开始 [12]，受 switchdev 感知设备驱动程序支持的影响，例如 [13]）。虽然 Neutron 不负责执行此查找（OVN 将执行），但它需要接受并转发此信息到 OVN。
因此，由 Nova 更新的端口的 binding:profile 属性预计包含以下信息
binding:profile={
"pci_vendor_info",
"pci_slot",
"physical_network",
"card_serial_number": "UNIQUEBOARDSERIAL",
"pf_mac_address": "de:ad:be:ef:ca:fe",
"vf_num": 42
}
有了这些信息，就可以识别正确的 OVN chassis 主机名和 SmartNIC DPU 主机侧的端口 representor。
OVN 机制驱动程序还需要更改（在相关情况下）以使用基于序列号查找的主机名，而不是依赖于传递到 binding_host_id 中的 hypervisor 主机名。
收到 Nova 的端口更新后，Neutron 需要在 OVN 数据库中创建相关的逻辑交换机端口（将必要的信息传达给 OVN的最终方法将根据 ovn-vif 上游 OVN 中的讨论结果确定）。
Logical_Switch_Port
options:requested-chassis=fqdn-of-a-smartnic-dpu-host
options:plug-type=representor
options:plug-mtu-request=1500
options:plug:representor:pf-mac=de:ad:be:ef:ca:fe
options:plug:representor:vf-num=0
如果未指定 vf-num，则应插拔 PF representor 而不是 VF representor。
端口绑定和端口功能¶
当前，为了支持硬件卸载，OVN 机制驱动程序的 bind_port 方法能够绑定类型为 direct 的端口，如果它们在其 binding:profile 属性中还提供了“switchdev”功能
binding:profile='{"capabilities": ["switchdev"]}'
该功能是通过 devlink 从 PCI(e) 端点发现的 - 当通过 PF 可见 NIC 交换机时，将“switchdev”功能添加到 Nova 跟踪的 PF 和 VF 中。SmartNIC DPUs 不会将 NIC 交换机暴露给 hypervisor 主机，因此未发现此功能。为了解决这个问题，相关的 Nova 规范 [7] 依赖于为使用 SmartNIC DPU 的目的而定义的新端口类型，称为 VNIC_REMOTE_MANAGED。neutron-lib 中已存在的 VNIC 类型 VNIC_SMARTNIC 已经被考虑过，但后来发现资源请求创建后发生调度会与 Ironic 用例发生冲突）。
需要扩展 OVN 机制驱动程序以处理 VNIC_REMOTE_MANAGED 端口。这将允许端口绑定代码选择正确的代码路径并触发 OVN 中的 representor 端口插拔逻辑。
