在端口 API 中暴露后端提示，提示 ovs-tx-steering

RFE: https://bugs.launchpad.net/neutron/+bug/1990842

引入一个端口属性，允许传递后端特定的提示，主要目的是允许后端特定的性能调优。

问题描述

我们的一些对性能敏感的用户希望在 OpenStack 下调整 Open vSwitch 的 Tx 包引导选项 [1]。

这自 Open vSwitch v2.17.0 起可用。 [2], [3]

提议的变更

我们建议引入两个新的扩展：port-hints 和 port-hint-ovs-tx-steering。

将此功能分解为两个扩展的目的是为了可扩展性：允许将来添加其他提示。port-hints 标志着一个新的端口属性的存在，详情如下。port-hint-foobar 标志着 Neutron 实例知道的新端口属性（或者说，提示）的值是什么。

port-hints 添加一个新的端口属性：hints。其默认策略是 admin_only。其值为一个字典（默认情况下为空）。字典的键是标准机制驱动程序别名，如 [4] 中所述。此规范仅允许一个键：openvswitch。其他机制驱动程序的键可能由后续规范引入。对于一个机制驱动程序，该值为一个可能的复杂结构，但至少在顶层是一个字典。在此规范中，我们仅部分定义其格式 - 引入一个提示。这由第二个扩展 port-hint-ovs-tx-steering 标记。其他提示的定义留给未来的规范。这里考虑一个创建端口请求的局部主体

{
    "port": {
        "hints": {
            "openvswitch": {"other_config": {"tx-steering": "thread"|"hash"}}}
        ...
}

hints 中的所有内容都解释为建议，而不是需求。也就是说，neutron 可以自由地忽略一些或全部请求的提示，而不会返回错误响应或将端口置于错误状态。特别是，当端口被不同的机制驱动程序绑定时，neutron 可以自由地忽略请求的提示。

hints 可以在创建端口或更新端口时设置，但不能保证在端口绑定后更新提示会有任何效果。

hints 故意不命名为 binding:hints，并且不应影响绑定过程和决策。

在 openstack CLI 中，我们建议将上述 API 功能公开为

openstack port create/set --hint HINT-ALIAS=HINT-VALUE [--hint ...] ...
openstack port unset --hints ...

例如

openstack port create --hint ovs-tx-steering=thread ...
openstack port create --hint ovs-tx-steering=hash ...

上述 CLI 语法允许键值类型的提示，并且可以扩展为允许布尔类型的提示（如果需要）。HINT-ALIAS=HINT-VALUE 和传递给 API 的完整数据结构之间存在任意但有文档记录的映射。openstack CLI 还允许在 –hint 参数中使用任意 JSON 值，并将其原样传递给 API。

在收到传递的 ovs-tx-steering 提示后，ovs-agent 可以设置相应的 OVS 接口的 other_config（当然使用 python 本地接口，而不是 ovs-vsctl）

sudo ovs-vsctl set Interface ovs-interface-of-the-port other_config:tx-steering=thread
sudo ovs-vsctl set Interface ovs-interface-of-the-port other_config:tx-steering=hash

提示 ovs-tx-steering 的默认值为 thread。

API 影响

在端口资源中添加一个新的 admin_only 字段，名为 hints。此字段可以在 GET、POST 和 PUT 请求中存在。此字段的长度不能超过 4095 个字符。有关其语义，请参见上述内容。

数据库影响

引入一个新的表 porthints 并将其与 ports 表自动连接。

客户端影响

osc 和 openstacksdk 中的相关更改。

测试

  • 单元测试。

  • neutron-tempest-plugin 中的 Tempest 测试。

负责人

参考资料