Netronome SmartNIC 启用

https://blueprints.launchpad.net/nova/+spec/netronome-smartnic-enablement

Netronome SmartNIC 允许在网卡上进行复杂的包处理。为了支持对它们的硬件加速，Nova 核心需要进行修改以支持它们支持的 VIF 和 OVS 插件组合。本规范提出了一种混合 SR-IOV 和 OVS 模型来实现加速。

问题描述

Netronome SmartNIC 能够将数据包直接路由到单个 SR-IOV 虚拟功能。这些可以使用 IOMMU (vfio-pci 直通) 或在计算节点上运行的低延迟 vhost-user virtio-forwarder 连接到虚拟机。数据包处理管道是通过运行支持启用数据平面匹配/动作规则硬件加速的自定义版本的 OVS 来管理的。

目前，Nova 支持多种类型的 OVS 插件：TAP 类插件、混合型 (veth 对 + linux-bridge) 插件或 vhost-user socket 插件。类型由桥接类型决定：基于 DPDK 的桥接使用 vhost-user，而“正常”桥接使用 vhost-net/TAP 或混合型，具体取决于使用的防火墙插件。

为了在 Netronome SmartNIC 上启用加速，Nova 需要两种额外的将虚拟机连接到 OVS 桥接的方法，同时消耗 PCIe 虚拟功能资源。此外，如果可以按端口为基础确定插件方法，那将是有益的。

用例

  • 最终用户应该能够以以下三种模式之一将端口连接到配备了 Netronome SmartNIC 和 OVS 的超visor 上运行的虚拟机

    • 正常：标准的基于内核的 OVS 插件。（混合或 TAP）

    • 直通：加速的 IOMMU 直通，适用于类似 NFV 的应用。（vfio-pci）

    • Virtio Forwarder：加速的 vhost-user 直通，与标准 virtio 驱动程序具有最大的软件兼容性，并支持实时迁移。（XVIO）

提议的变更

  • 添加额外的 SR-IOV VNIC 类型

    • Nova 的网络模型为端口提供了以下 VNIC 类型选项

      • normal

      • direct

      • macvtap

      • direct-physical

      • baremetal

    • 建议将此列表扩展为

      • virtio-forwarder

  • 在 neutron API 部分添加逻辑以实现 PCI 预留

    • 在 nova/network/neutronv2/api.py 中，需要在 create_pci_requests_for_sriov_ports 中添加第二个检查，以便在 VNIC 类型设置为 direct 或 virtio-forwarder 时为 OVS 网络分配 PCI 请求。将 VF 类型选择参数发送到 Nova 作为 PCI 供应商/产品 ID 是不可取的，应该进一步开展工作以开发一种能够抽象这种细节的 capability 或驱动程序列表。有关更多详细信息，请参阅 IRC 聊天记录：http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-04-14.log.html#t2017-04-14T14:44:06

  • 由于 Agilio OVS 是 upstream OVS 的一个分支版本，因此需要一个基于 OVS OS-VIF 插件的外部 OS-VIF 插件。

    • 应该为这两种插件类型添加新的端口配置文件

      • VIFPortProfilePassthrough：用于直通插件

      • VIFPortProfileForwarder：用于 Virtio Forwarder 插件

    • 在 nova/network/os_vif_util.py:_nova_to_osvif_vif_ovs 中添加逻辑，根据 VNIC 类型进行选择。

  • 补充说明

    • 从大多数 Neutron 部分的角度来看，此解决方案看起来像未修改的 OVS

      • 流规则像正常一样编程。

      • 端口在桥接上使用与标准 OVS 解决方案相同的元数据进行注释。

      • 可以使用标准的 Neutron 插件或 ML2 驱动程序。

    • OS-VIF 插件需要在超visor 上运行命令来配置虚拟功能和句柄。这很可能是特定于供应商的，可以调用用户可替换的脚本或在 OS-VIF 自定义插件中实现。

    • 部署者/管理员仍然需要在 nova.conf 中使用 pci_passthrough_whitelist 和 pci_alias 在超visor 上注册 PCI 设备。

    • 启用了 SmartNIC 的节点和经典节点可以并排运行。标准的调度过滤器会根据端口类型和驱动程序功能分配和放置虚拟机。

    • 已经提交了一个概念验证实现：该实现在本蓝图中跟踪。为了方便起见，常量和新添加的内容都以关键字“Agilio”命名。这将替换为与供应商无关的 SmartNIC 术语。

    • 需要在 Neutron API 上记录一个 RFE，以修改它以将 virtio-forwarder 识别为 binding:vnic_type 的有效选项。

备选方案

  • 添加新的 OVS 桥接类型

    • 这将强制所有连接到该桥接的虚拟机使用一种加速类型。对代码的影响将更大。

  • 添加 glance 或 flavor 注解

    • 这将强制虚拟机具有一种加速类型。代码可能会移动到更多的 VIF 类型，并且仍然需要更新虚拟功能预留。

数据模型影响

无

REST API 影响

无

安全影响

OS-VIF 插件需要提升权限，与其他 OS-VIF 插件类似。

通知影响

无

其他最终用户影响

python-neutronclient 应该接受 virtio-forwarder VNIC 类型，除了当前 VNIC 类型列表之外。

性能影响

这段代码很可能在 VIF 插件和断开连接时被调用。预计性能不会下降。

在加速端口上，虚拟机之间的数据平面性能预计会提高。

其他部署者影响

部署者仍然需要在部署时配置 SmartNIC 版本的 OVS 并配置 Nova 中的 PCI 白名单。这不需要核心 OpenStack 更改。

开发人员影响

核心 Nova 语义略有改变。ovs 网络现在将支持更多的 VNIC 类型。

实现

负责人

主要负责人

Jan Gutter <jan.gutter@netronome.com>

其他贡献者

Imran Khakoo <imran.khakoo@netronome.com> Monique van den Berg <mvandenberg@netronome.com>

工作项

  • 修改概念验证实现，使其更具供应商中立性，包括对 OVS-TC 主题的支持：https://review.openstack.org/#/q/topic:ovs_acc

  • 生成外部 OS-VIF 插件，复制 OVS 插件所需的函数。

  • 开发基于能力或驱动程序类型选择 VF 的可接受方法。

  • 更新单元测试。

  • 生成面向用户的文档。

依赖项

  • Netronome SmartNIC 驱动程序可用。

测试

将为新的语义添加单元测试，将在 Netronome 使用第三方 CI 系统进行功能测试。

文档影响

将生成一个类似于 SR-IOV 直通可用指南的 SmartNIC 加速用户指南

https://docs.openstack.org/ocata/networking-guide/config-sriov.html

参考资料

Agilio OVS：https://www.netronome.com/products/agilio-software/agilio-ovs-software/

Agilio OVS 防火墙：https://www.netronome.com/products/agilio-software/agilio-ovs-firewall-software/

XVIO：https://www.netronome.com/solutions/xvio/overview/

历史

修订版

发布名称

描述

Pike

引入