6.3 KiB

Raw Blame History

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¹ introduced the capability of creating a port that could use the hardware offload support implemented in Open vSwitch². This feature was implemented in the following set of patches (initially for ML2/OVS):³, ⁴ and⁵.

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⁶ ⁷).

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.

**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.

6.3 KiB Raw Blame History