启用 SR-IOV 物理函数到实例的直通

https://blueprints.launchpad.net/nova/+spec/sriov-physical-function-passthrough

Nova 已经支持通过其 libvirt 驱动程序进行 PCI 设备的直通几个版本了，在此期间，代码已经过了一些稳定化和一些小的功能添加。

对于启用了 SR-IOV 的网卡，可以将网卡上的任何端口视为多个虚拟设备（称为 VF - 虚拟函数）或完整设备（PF - 物理函数）。

Nova 当前的处理方式仅将虚拟函数作为实例可以请求的资源公开 - 并且到目前为止，这是最常见的用例。 然而，随着虚拟化网络应用程序的需求增加，有时需要让实例完全控制端口，而不仅仅是一个虚拟函数。

OpenStack 被视为 NFV 用例的核心技术之一，并且已经有很多工作致力于使 OpenStack 和 Nova 具备 NFV 功能，因此我们希望确保消除这些小的剩余差距。

问题描述

目前，将物理函数直通到 OpenStack 实例是不可能的，但某些 NFV 应用程序需要完全控制端口，而另一些应用程序则可以使用 SR-IOV 启用网卡的 VF。 使用相同的网卡能够做到这一点是有益的，因为在计算主机粒度以下预配置资源难以管理，并且违背了 Nova 提供按需资源的初衷。 我们希望能够通过分配 PF 来为某些实例提供对端口的无限访问权限，但在 PF 未被使用时恢复使用 VF，从而确保可用资源的按需配置。 然而，并非每张 SR-IOV 网卡及其各自的 Linux 驱动程序都能够做到这一点，在这种情况下，某些端口需要由管理员提前预配置为 PF 或 VF。

这意味着 Nova 必须跟踪哪些 VF 属于特定的 PF，并确保这反映在资源跟踪的方式中（因此，即使使用单个 VF 也意味着相关的 PF 不可用，反之亦然，如果 PF 正在使用，则其所有 VF 都标记为已使用）。

Nova 中 PCI 设备管理代码当前会过滤掉任何物理设备（当前是硬编码的）。 此外，Nova 中 PCI 设备资源的建模当前假定扁平层次结构，资源跟踪逻辑不理解可以暴露给 Nova 的不同 PCI 设备之间的关系。

用例

某些 NFV 工作负载可能需要完全控制物理设备，以便使用 VF 中不可用的某些功能，绕过某些网卡对 VF 施加的限制，或独占使用端口的全部带宽。 然而，由于弹性云的动态特性以及 Nova 提供按需资源的承诺，我们不希望必须预配置某些 SR-IOV 网卡用作 PF，因为这违背了基础设施管理工具的承诺，该工具允许快速重新利用资源。

现代 SR-IOV 启用网卡及其驱动程序通常允许在飞行中进行此类重新配置，因此一旦特定主机上不再需要 PF 直通（例如，使用它的实例被移动或删除），PF 将绑定回其 Linux 驱动程序，从而启用 VF 的使用，前提是返回设备时完成初始化步骤（如果有需要）。 然而，由于市场上可用的设备和驱动程序的范围广泛，因此无法保证这始终有效，因此我们希望确保 Nova 有一种方法可以告知其网卡处于某种配置并且不能假定可以重新配置。

通过使 Nova 数据模型有用地表达 PF 及其 VF 之间的关系，将启用其他用例（这将需要进一步的工作）。 其中一些已经作为单独的规范提出（参见 [1] 和 [2]）。

提议的变更

我们需要解决的两个问题是

  1. 如何启用请求完整的物理设备。 这意味着扩展 InstancePCIRequest 数据模型以能够容纳此信息。 由于探测系统并具有有关设备是 PF 还是 VF 的信息的 Spec 对象构建逻辑的白名单解析逻辑，因此足以将 physical_function 字段添加到 PCI 别名模式和 PCIRequest 对象中。

  2. 启用基于现在可以针对整个设备进行请求的调度和资源跟踪。 这意味着扩展 PCIDevices 的数据模型以保存有关物理和虚拟函数之间关系的信息（该关系已经记录，但格式不合适），并且扩展我们向资源跟踪器（又名 PCIDeviceStats 类）公开的有关 PCI 设备的聚合数据的方式，以便能够呈现 PF 及其计数，并确保跟踪在声明/使用 PF 时将变得不可用的相应 VF。

此外，我们将希望确保白名单语法支持直通 PF。 事实证明，这只需要很少的更改。 当前，如果白名单条目指定 PF 的地址或 devname，则匹配代码将确保任何 VF 都匹配。 这种行为，加上允许跟踪 PF 的 Nova（通过删除跳过任何 PF 的硬编码检查），应该足以允许管理员所需的灵活性。 仅仅默认将所有 VF 与 PF 一起列入白名单，如果 PF 地址被列入白名单，就可以为我们提供所需的灵活性，同时保持向后兼容性。

与当前实现一样，需要在具有可以直通的 PCI 设备的宿主机上进行一些初始配置。 除了启用 SR-IOV 和配置网卡以及 Nova 所需的白名单配置设置之外，管理员可能还需要添加一种自动方法（例如 udev 规则）来重新启用 VF，因为根据使用的驱动程序和网卡，在 VM 获得对端口的完全控制权并将设备从宿主机驱动程序解绑后，任何现有配置都可能丢失。

为了使 PF 充当 Neutron 端口，需要进行一些超出此蓝图范围的额外工作。 我们旨在使此处所需的内部 Nova 更改成为重点，并将集成工作推迟到未来的（可能跨项目）蓝图。

备选方案

没有真正的替代方案涵盖所有用例。 一种仅涵盖带宽要求的替代方案是允许单个实例保留单个 PF 的所有 VF，同时仅使用单个 VF，从而有效地保留带宽。 除了不是所有应用程序的解决方案外，它也不会减少更改的复杂性，因为仍然需要在 Nova 中对 VF 之间的关系进行建模。

数据模型影响

即使目前有一种方法可以确定单个 VF 属于哪个 PF（通过使用 extra_info 自由格式字段），但可能需要添加更“便于查询”的关系，这将允许我们回答“给定一个 PCI 设备记录是 PF，它包含哪些 VF 记录”。

这很可能作为对同一表的外部键关系实现，并且将添加对象支持，但实际的实现讨论更适合实际的代码提案审查。

还需要能够在调度中使用的 PCI 设备数据的聚合视图中了解 PF 和 VF 之间的关系，因此需要更改 PCIDeviceStats 持有聚合数据的方式。 这也将导致对过滤/声明逻辑的更改，其程度可能会影响数据模型决策，因此最好在实际的实现更改中进行讨论。

REST API 影响

不需要 API 更改。 PCI 设备是通过在 flavor extra-specs 中指定设备规范的别名来请求的。 当前，设备规范及其别名是 Nova 部署配置的一部分，因此是部署特定的。

安全影响

无

通知影响

无

其他最终用户影响

无 - 非管理员用户将继续仅使用通过 flavor extra-specs 公开给他们的内容，而他们无法以任何方式修改这些内容。

性能影响

需要 PCI 直通设备的实例的调度将在比当前 PF 请求的情况下更多地工作和处理更多的数据。 然而，这不太可能对性能产生任何明显的影响。

其他部署者影响

PCI 别名语法将变得更具功能性，以便能够专门请求 PF。

开发人员影响

无

实现

负责人

主要负责人

Nikola Đipanov <ndipanov@redhat.com>

其他贡献者

Vladik Romanovsky <vromanso@redhat.com>

工作项

  • 重构 DB 模型和相应的对象，以在 PF 条目及其相应的 VF 之间建立显式关系。 更新 PCI 管理器类中的声明逻辑，以便声明/分配 PF 声明其所有 VF，反之亦然。

  • 更改 PCIDeviceStats 类以在其池中公开 PF，并更改声明/消耗逻辑以在消耗或声明 PF 时声明适当数量的 VF。 完成此工作项后，所有调度和资源跟踪逻辑都将意识到 PF 约束。

  • 通过 pci_alias 配置选项添加支持指定 PF 要求，以便可以通过 flavor extra-specs 请求它。

依赖项

无

测试

此处提出的更改仅扩展了现有功能，因此需要更新当前测试套件以确保涵盖新功能。 预计当前到位进行的测试是为了防止对现有功能的任何回归。 不需要添加新的测试套件来支持此功能，只需要新的测试用例。

文档影响

Nova 中 PCI 直通功能的文档需要更新以反映上述更改 - 也就是说 - 没有什么不寻常的影响。

参考资料

历史

可选部分，用于 Mitaka，每次更新规范时使用，以描述新的设计、API 或任何数据库模式更新。有助于让读者了解随着时间的推移发生了什么。

修订版

发布名称

描述

Mitaka

引入