Generic os-vif datapath offloads

https://blueprints.launchpad.net/nova/+spec/generic-os-vif-offloads

现有的 os-vif 方法是通过 VIFPortProfileOVSRepresentor 端口配置文件对象传递 datapath offload 元数据。 目前，这被 ovs 参考插件和外部 agilio_ovs 插件使用。 本规范建议重构接口，以支持更多 VIF 类型和 offload 模式。

问题描述

Offloads 背景

在撰写本规范时，很明显“offloads”一词具有历史意义，导致对本规范范围的混淆。 添加此小节是为了阐明不同类别的 offloads 之间的区别。

协议 Offloads

许多平台上的专用外设处理网络特定计算已得到广泛建立。 对于 Linux，ethtool man page 详细介绍了许多 NIC 上可用的 --offload 选项的设置，用于特定协议。

ethtool 类型的 offloads 通常

  1. 对访客（和主机）可用，

  2. 与网络端点有很强的关系，

  3. 在生成和消耗数据包方面发挥作用，

  4. 可以建模为实例上的虚拟 NIC 的功能。

目前，Nova 对这些类型的 offload 功能建模很少。 确保实例可以迁移到能够提供所需功能的计算节点是 Nova 当前无法提前确定的。

本规范仅轻触这一类 offloads。

Datapath Offloads

最近，出现了允许在 NIC 上进行复杂数据包处理的 SmartNIC。 这允许在主机控制下实现诸如桥接器和路由器之类的构造。 与 procotol offloads 相比，这些 offloads 适用于数据平面。

在 Open vSwitch 中，数据平面可以通过例如内核数据平面（openvswitch.ko 模块）、用户空间数据平面或 tc-flower 分类器来实现。 反过来，tc-flower 分类器的部分可以委托给 SmartNIC，如本文档中描述的 TC Flower Offload paper 中所述。

注意

Open vSwitch 将其数据包处理管道的特定实现称为 datapaths，而不是 dataplane。 本规范遵循 datapath 术语。

Datapath offloads 通常具有以下特征

  1. 控制和管理这些 offloads 的接口由主机控制。

  2. 可以描述诸如路由、隧道、NAT 和防火墙之类的网络级操作。

  3. 可能需要特殊的插拔模式，因为数据包可能完全绕过主机 hypervisor。

最简单的情况是 SR-IOV NIC 在虚拟以太网桥接 (VEB) 模式下，如 sriovnicswitch Neutron 驱动程序所用。 需要特殊的插拔模式（即 IOMMU PCI 直通），并且 hypervisor 使用所需的 MAC ACL 过滤器配置 VEB。

本规范侧重于这一类 offloads。

混合 Offloads

未来，可以将 datapath offloads 作为服务推送到访客实例。 特别是，可信的 NFV 实例可能会获得对数据包处理管道部分访问权限，具有各种级别的隔离和组合。 本规范不针对此用例。

核心问题陈述

为了支持 datapath offloads 的硬件加速，Nova 核心和 os-vif 需要对 datapath offload 插拔元数据进行建模。 现有的 os-vif 方法是通过 VIFPortProfileOVSRepresentor 端口配置文件对象传递此数据。 这被 ovs 参考插件和外部 agilio_ovs 插件使用。

随着 vrouter 成为此类元数据的潜在第三个用户（如 vrouter 硬件 offloads 蓝图 中建议），在模式进一步固化之前抽象接口是值得的。

本规范仅限于重构接口，同时考虑到未来的扩展，并允许现有的插件保持功能。

SmartNICs 能够将数据包直接路由到单个 SR-IOV 虚拟功能。 这些可以使用 IOMMU (vfio-pci 直通) 或低延迟 vhost-user virtio-forwarder 连接到实例，该 virtio-forwarder 在计算节点上运行。

在 Nova 中，VIF 应该完全描述实例如何插入到 datapath 中。 这包括 hypervisor 执行所需插拔的信息，以及 datapath 控制软件的信息。 对于 ovs VIF，hypervisor 通常也能够执行 datapath 控制，但对于每种 VIF 类型而言并非如此（因此 os-vif 的存在）。

VNIC 类型是 VIF 的属性。 它已经承担了描述 VIF 的特定“插拔模式”的语义。 在 Nova 网络 API 中，有一个 VNIC 类型列表，如果 Neutron 将带有其中一种 VNIC 类型设置的 VIF 传递给 Nova，则会触发 PCI 请求。 Open vSwitch offloads 使用以下 VNIC 类型来区分 offload 模式

  • normal（或默认）VNIC 类型表示实例已插入软件桥接器。

  • direct VNIC 类型表示 VF 已传递到实例。

此外，Agilio OVS VIF 类型实现了以下 offload 模式

目前，os-vif 和 Nova 实现了 switchdev SR-IOV offloads 用于 Open vSwitch，并使用 tc-flower offloads。 在此模型中，主机上的 representor netdev 与每个虚拟功能相关联。 此 representor 充当 NIC 数据包处理管道上相应虚拟端口的句柄。

Nova 将其从 PCI 请求收到的 PCI 地址传递给 os-vif 插件。 可选地，也可以传递 netdev 名称，以便 os-vif 插件友好地重命名 representor。

ovs 和 agilio_ovs os-vif 插件然后查找 VF 的关联 representor 并执行 datapath 插拔。 从 Nova 的角度来看，hypervisor 随后使用来自 VIFHostDevice os-vif 对象（带有 direct VNIC 类型）直通 VF，或使用来自 VIFVHostUser os-vif 对象（带有 virtio-forwarder VNIC 类型）将实例插入 vhost-user 句柄。

在两种情况下，os-vif 对象都具有 VIFPortProfileOVSRepresentor 端口配置文件，该配置文件携带 offload 元数据以及 Open vSwitch 元数据。

用例

目前，switchdev VF offloads 仅针对一个端口配置文件建模。 如果开发人员使用不同的 datapath，希望将 offload 元数据传递给 os-vif 插件，他们将不得不扩展对象模型，或者使用令人困惑的命名对象。 本规范旨在建立一个推荐的机制来扩展对象模型。

提议的变更

使用组合而不是继承

不要使用基于继承的模式来建模 offload 功能和元数据，而是使用组合模式

  • 实现 DatapathOffloadBase 类。

  • 将其子类化为 DatapathOffloadRepresentor，其中包含以下成员

    • representor_name: StringField()

    • representor_address: StringField()

  • 将 datapath_offload 成员添加到 VIFPortProfileBase

    • datapath_offload: ObjectField('DatapathOffloadBase', nullable=True, default=None)

  • 更新 os-vif OVS 参考插件以接受和使用新的版本和字段。

未来的 os-vif 插件将现有形式的 datapath offload（例如，switchdev offload）与新的 VIF 类型结合使用，无需修改 os-vif。 未来的 datapath offload 方法需要子类化 DatapathOffloadBase。

为了避免实现潜在的脆弱的后向兼容代码，此选项建议在 Nova 中至少保持两个并行接口在重叠发布周期内处于活动状态，然后再更新 os-vif 中的 Open vSwitch 插件。

与其增加对象版本并创建组合版本映射，此选项建议故意忽略版本直到 os-vif 的下一个主要版本。 目前，Nova 和 os-vif 插件中未使用 os-vif 中的版本协商和后向兼容。

Kuryr Kubernetes 也是 os-vif 的用户，并且以尚未公开支持的 os-vif 方式使用对象版本。 正在进行 讨论 尝试为 Kuryr 的用例找到解决方案。

如果还需要在 os-vif 中建模协议 offloads，VIFBase 或 VIFPortProfileBase 可以获得 protocol_offloads 功能列表。

受影响的插拔方法摘要

  • 更改前

    • VIF 类型：ovs（os-vif 插件：ovs）

      • VNIC 类型：direct

      • os-vif 对象：VIFHostDevice

      • port_profile: VIFPortProfileOVSRepresentor

    • VIF 类型：agilio_ovs（os-vif 插件：agilio_ovs）

      • VNIC 类型：direct

      • os-vif 对象：VIFHostDevice

      • port_profile: VIFPortProfileOVSRepresentor

    • VIF 类型：agilio_ovs（os-vif 插件：agilio_ovs）

      • VNIC 类型：virtio-forwarder

      • os-vif 对象：VIFVHostUser

      • port_profile: VIFPortProfileOVSRepresentor

  • 采用此模型后，Nova

    • VIF 类型：ovs（os-vif 插件：ovs）

      • VNIC 类型：direct

      • os-vif 对象：VIFHostDevice

      • port_profile: VIFPortProfileOpenVSwitch

      • port_profile.datapath_offload: DatapathOffloadRepresentor

    • VIF 类型：agilio_ovs（os-vif 插件：agilio_ovs）

      • VNIC 类型：direct

      • os-vif 对象：VIFHostDevice

      • port_profile: VIFPortProfileOpenVSwitch

      • port_profile.datapath_offload: DatapathOffloadRepresentor

    • VIF 类型：agilio_ovs（os-vif 插件：agilio_ovs）

      • VNIC 类型：virtio-forwarder

      • os-vif 对象：VIFVHostUser

      • port_profile: VIFPortProfileOpenVSwitch

      • port_profile.datapath_offload: DatapathOffloadRepresentor

其他影响

os-vif 需要发布一个版本，然后这些配置文件才能用于 Nova 中的通用 CI 测试。 完成后，Nova 可以适应使用新的通用接口。

  • 在 Stein 中，os-vif 的对象模型将获得本规范中描述的接口。 如果需要，将发布 os-vif 的主要版本。

  • 然后，Nova 将依赖于新版本并使用新接口来获取新插件。

  • 在此期间，os-vif 将具有两个并行接口来支持此元数据。 预计这将持续至少从 Stein 到 Train。

  • 从 Train 开始，应将现有插件过渡到新模型。

  • 一旦所有插件都已过渡，就可以在 os-vif 的主要版本中删除并行接口。

  • 在此期间，将为 Kuryr Kubernetes 提供支持，以过渡到更好的支持模型。

其他说明

  • Neutron 中不需要相应的更改：目前 os-vif 由 Nova 和 Kuryr Kubernetes 消耗。

  • 即使目前将 representor 地址建模为 PCI 地址对象，但认为更严格的类型检查收益有限。 未来的网络系统可能需要路径、UUID 或其他描述 representor 的方法。 将地址成员保留为字符串被认为是一种可接受的妥协。

  • 对组合而不是继承的主要担忧是对象序列化大小的增加。

备选方案

在开发本规范时，尚不清楚组合模型或继承模型将是共识解决方案。 由于这两种模型对未来的代码具有截然不同的影响，因此决定实现两者，以便进行比较和对比。

继承模型的实现说明于 https://review.openstack.org/608693

使用继承创建通用的 representor 配置文件

继续使用基于继承的模式来建模 offload 功能和元数据

  • 通过继承 VIFPortProfileBase 实现 VIFPortProfileRepresentor，并添加以下成员

    • representor_name: StringField(nullable=True)

    • representor_address: StringField()

继承模型中可用新插拔方法的摘要

  • os-vif 更改后

    • 具有 SR-IOV 直通的通用 VIF

      • VNIC 类型：direct

      • os-vif 对象：VIFHostDevice

      • port_profile: VIFPortProfileRepresentor

    • 具有 virtio-forwarder 的通用 VIF

      • VNIC 类型：virtio-forwarder

      • os-vif 对象：VIFVHostUser

      • port_profile: VIFPortProfileRepresentor

考虑的其他替代方案

其他建议的替代方案需要对 Nova 和 os-vif 进行更具侵入性的补丁

  • 为每种未来的 datapath/offload 组合创建一个新的 VIF 类型。

  • 可以通过将 VIFPortProfileOVSRepresentor 类重命名为 VIFPortProfileRepresentor 来使基于继承的模式更通用，如 https://review.openstack.org/608448 中所示

  • 可以通过使用合适的协商机制来提供重叠来对版本化对象进行后向兼容。

数据模型影响

无

REST API 影响

无

安全影响

os-vif 插件以提升权限的方式运行，但不会实现任何新功能。

通知影响

无

其他最终用户影响

无

性能影响

以这种方式扩展模型会向传递给 os-vif 插件的 VIF 对象中添加更多字节。目前，这种影响可以忽略不计，但当对象被序列化并通过网络传输时，这将增加 API 消息的大小。

然而，在对象模型经历重大版本变更并进行重新设计之前，这个问题不太可能出现。

其他部署者影响

如果 Nova、os-vif 或 os-vif 插件不同步，部署者可能会在日志中看到弃用警告。

开发人员影响

核心 os-vif 语义将略有改变。扩展 os-vif 对象的方式将得到更明确的定义。

升级影响

Nova 中 os-vif 的最低版本将在 requirements.txt 和 lower-constraints.txt 中进行更新。部署者应遵循至少这些最低版本要求。

实现

负责人

主要负责人

Jan Gutter <jan.gutter@netronome.com>

工作项

依赖项

  • 在审查完这两个选项，并将选定的版本合并后，需要发布一个 os-vif 版本。

  • 在将 Nova 更新为使用较新的 os-vif 版本时，应进行相应的更改以远离已弃用的类。预计此更改将是最小的。

测试

  • os-vif 更改的单元测试将测试对象模型的影响。

  • 第三方 CI 已经测试了加速插拔模式，无需测试任何新功能。

文档影响

os-vif 开发文档将使用新类进行更新。

参考资料