[rfe] Non-admin users unable to create SR-IOV switch dev ports

As discussed at the bobcat PTG operator session: https://etherpad.opendev.org/p/neutron-bobcat-ptg

This RFE has been approved with the following comments (see drivers meeting logs):
* Create a SPEC.
* The RFE will propose a new port extension, e.g. hardware_offload, that will replace the port binding definition.
* The feature will be implemented in 2 phases:
** Create the port extension, changes in the SDK/CLI code and Neutron core. But pass to Nova the port binding information as before. That will avoid the need to make any change in the Nova code yet.
** Once implemented, remove the Neutron code that changes the port binding information.

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-specs/+/882272

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-lib/+/882726

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/882832

Reviewed: https://review.opendev.org/c/openstack/neutron-specs/+/882272
Committed: https://opendev.org/openstack/neutron-specs/commit/ec0a0fb2a2b3eb71b7d08d39b2d73ec9de55b537
Submitter: "Zuul (22348)"
Branch: master

commit ec0a0fb2a2b3eb71b7d08d39b2d73ec9de55b537
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Thu May 4 11:18:39 2023 +0000

    Port extension to create hardware offloaded ports

    The aim of the RFE is to create a new port extension to allow to create
    ports with hardware offloaded capabilities.

    Related-Bug: #2013228
    Change-Id: I0ee77fd4a0b1fe28b206db7dc13e105ffff122a6

Change abandoned by "Slawek Kaplonski <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/882832
Reason: This review is > 4 weeks without comment, and failed Zuul jobs the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Thank you for your efforts on this. Appologies that I only just spotted there was progress.

My main question is why does the user need to request that the direct port is hardware offloaded?

As a user I don't need to create different ports when my operator has installed OVN vs OVS? This seems a very similar case where the direct mode port happens to be implemented differently?

Granted there are cases in a mixed cloud where you might need both types of direct port. I have never seen such a cloud myself, and we use a lot of hardware offloaded direct mode ports. It would be nice to configure a default for a given cloud, i.e. default to hardware offload. Then any user that cares about the distinction gets to request the specific one?

Hello John:

We discussed this during the PTG. The HW offload capability is requested in the port definition, this is not implicit in the backend. As you commented, any HW offload deployment can host kernel and HW offloaded ports.

The other justification is that, by default in Neutron, we don't implement config driven API features. In other words: we don't implement variables that change the API, in this case the port creation, always defining this new parameter to "switchdev".

Now we have defined a parameter outside the port binding dictionary, you can lecture your users to request both "direct" and "hardware_offload_type" in the port creation definition.

Regards.