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
This commit is contained in:
Rodolfo Alonso Hernandez 2023-05-04 11:18:39 +00:00
parent d1eca25a3f
commit 739ac589f1
1 changed files with 220 additions and 0 deletions

View File

@ -0,0 +1,220 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=================================================
Port extension to create hardware offloaded ports
=================================================
Launchpad bug: https://bugs.launchpad.net/neutron/+bug/2013228
The aim of the RFE is to create a new port extension to allow to create ports
with hardware offloaded capabilities.
Problem Description
===================
The RFE [1]_ introduced the capability of creating a port that could use the
hardware offload support implemented in Open vSwitch [2]_. This feature was
implemented in the following set of patches (initially for ML2/OVS): [3]_,
[4]_ and [5]_.
In order to create a port with hardware offload capabilities, it is needed to
define the VNIC type and set a specific value in the port binding profile::
openstack port create --vnic-type direct \
--binding-profile '{"capabilities": ["switchdev"]}' port_hwol
This method to create a port has several drawbacks:
* The port binding profile field is an admin only parameter by default.
The values contained in this field can have references to PCI addresses of
the host and should not be modified by a non-admin user.
* Actually this parameter should not be written by Neutron, only by Nova when
the port is bound.
Proposed Change
===============
This RFE proposes to create a new port extension, called "hardware-offload",
that will replace the need of manually defining the port binding profile
information when creating the port; please note the I'm referring only to the
port creation process. This API extension consists on a boolean flag parameter
that will be "False" by default.
This new flag will be passed to Nova along with the port information
dictionary. Nova will use this flag instead of the port binding profile
information to command ``os-vif`` to create the corresponding layer 1 port
(a devlink port [3]_ [6]_).
Because of this Nova-Neutron communication, this RFE is going to be implemented
in two steps:
* The first one will implement only the Neutron and OSC (plus the OpenstackSDK
bits) code. The port dictionary passed to Nova will contain both the new flag
added in this RFE and the port binding profile, that will be added internally
by Neutron when the flag is enabled.
* The second step involves the Nova implementation. This changes implies that
Nova can read the port flag and create the corresponding port. The port
binding profile information passed by Neutron will be irrelevant.
.. NOTE::
The scope of this RFE, as discussed during the presentation of this new
feature in the Neutron drivers meeting, involves only the first step. The
Nova code change will be covered in other RFE and spec.
Client Impact
-------------
The OSC and OpenstackSDK projects will be updated in order to be able to create
a port using this new extension. Port creation example::
openstack port create --vnic-type direct --hardware-offload port_hwol
The new boolean field will be visible when showing the port resource.
REST API Impact
---------------
Proposed attribute::
RESOURCE_ATTRIBUTE_MAP = {
port.COLLECTION_NAME: {
"hardware_offload": {
'allow_post': True,
'allow_put': False,
'convert_to': converters.convert_to_boolean_if_not_none,
'default': False,
'is_visible': True,
'is_filter': True
}
}
}
Sample REST calls::
POST /v2.0/ports
{
"port": {
...
"hardware_offload": "True"
}
Response:
{
"port": {
"id": "<id>",
...
"hardware_offload": "True"
}
}
Data Model Impact
-----------------
This RFE proposes to create a child table to ``ports``, called
``port_hardware_offload``.
.. table:: **Port hardware offload**
================ ======== ==== ==============================================
Attribute Type CRUD Description
================ ======== ==== ==============================================
port_id uuid-str RO Unique identifier for the port object
hardware_offload bool RO Flag to indicate if the port is a devlink port
================ ======== ==== ==============================================
Security Impact
---------------
By default, this new field will be writable by the admin only. However, the
admin can consider changing the rule owner and allow any project user to create
a port enabling this flag::
policy.DocumentedRuleDefault(
name='create_port:hardware_offload',
check_str=base.ADMIN,
scope_types=['project'],
operations=ACTION_POST
)
This rule change was completely discouraged for the rule
'create_port:binding:profile' for the reasons provided in the problem
description.
Performance Impact
------------------
The port resource view will now require a new "JOIN" operation between the
``ports`` table and the ``ports_hardware_offload`` table when building the
port OVO. However there will be a 1:1 relationship between both tables and the
data retrieved from the child table is minimal (two columns).
Other Impact
------------
None.
Implementation
==============
Assignee(s)
-----------
Primary assignees:
Rodolfo Alonso Hernandez <ralonsoh@redhat.com> (IRC: ralonsoh)
Work Items
----------
* API implementation (neutron-lib and Neutron).
* Database migration (Neutron)
* CLI implementation (OpenstackSDK and OSC)
* Documentation.
* Tests and CI related changes.
Testing
=======
* Unit/functional tests.
* Fullstack API tests.
Documentation Impact
====================
User Documentation
------------------
Document the new way to create hardware offload ports and deprecate the older
method.
References
==========
.. [1] [RFE] SR-IOV accelerated OVS integration
https://bugs.launchpad.net/neutron/+bug/1627987
.. [2] https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330606.html
.. [3] https://review.opendev.org/c/openstack/os-vif/+/460278
.. [4] https://review.opendev.org/c/openstack/neutron/+/275616
.. [5] https://review.opendev.org/c/openstack/neutron/+/499203
.. [6] https://www.kernel.org/doc/html/next/networking/devlink/devlink-port.html