[RFE] Add a port extension to set/define the switchdev capabilities

[Rodolfo Alonso]

The aim of this RFE is to decouple the port binding profile update and the ability of a user to set the "switchdev" flag on a port.

Since [1], a user is able to set "{"capabilities": ["switchdev"]}" on the port binding profile in order to define this port as compatible with the Ethernet switch device driver model (switchdev) [2]. In other words, to be able to use a VF of a NIC with offloading capabilities. This is currently used in ML2/OVS and ML2/OVN to offload the OpenFlow rules on the NIC hardware.

The problem resides on the need of changing the port binding profile from the Neutron side:
* The port binding profile is a port blob that should be updated only from Nova.
* By default, this is allowed only to admin users, by is configurable via policy config. That could introduce security issues is a non-admin user can change any port binding profile, even if that is restricted to his/her own project.

This RFE will require a spec describing the needed changes on the API side, the port object and RPC blob transmitted (needed by Nova).

[1]https://review.opendev.org/c/openstack/neutron/+/499203
[2]https://www.kernel.org/doc/html/latest/networking/switchdev.html

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/854369

[Lajos Katona (lajos-katona)]

We discussed this RFE on the last drivers meeting, see the logs in [1], The agreement was to continue the discussion because nova side changes seems to be also necessary.

[1]: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-08-26-14.00.log.html#l-53

[sean mooney (sean-k-mooney)]

i think this should only be done via nova unless we want to enable scheduling based on the network backend.

in either case, we should not expose an extension to set/define the switchdev capability.

that is the wrong level of absraction.
i am creating a specless blueprint to resolve this in nova alone which will not address scheduling since that is an existing gap that will require more discussion.

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Hi Sean:

Please correct me if I'm wrong. From the Neutron side, the goal of this BZ if to create an extension in the port resource (the dictionary passed to Nova) indicating if the port has "switchdev" capabilities. That will prevent Neutron (and any non-admin user) from modifying the port binding dictionary (that should be updated by Nova only). With this change, a non-admin user will be able to create a "switchdev" port without having write access to the port binding dict.

The "switchdev" does not depend on the network backend, we can have both kernel and "switchdev" ports in the same OVS instance. Via scheduling, we can decide what hosts have this kind of resource, but from Neutron we should be able to create this kind of resource (logical resource, you know Neutron does not create the L1 resources).

Regards.

[sean mooney (sean-k-mooney)]

we could alow ports to request traits once we track pci device for neturon network in placement but until then i don't think you should attepent to provide any extension in neutron for this.

in the future we can use the existing port resource request mechanism that we use for bandiwht or pps qos to request 1 VF with switchdev trait

but until we report the VF to placement which will not happen until the B cycle neutron does not need to have any changes. to enable this.

in the b cycle if downstream constraints allow i hope we can complete pci device tracking in placement such that we will also tack pci device that coan be consumed via neutron port but that wont happen in A.