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 “port-hardware-offload”, that will replace the need of manually defining the port binding profile information when creating the port; please note that this is referring only to the port creation process. This API extension consists of a string parameter that will be “None” by default. This string will be the hardware offload type; OpenStack Neutron and Nova are currently supporting only “switchdev” [6]. The strings allowed by the API will be limited to a set of defined constants.

This new string parameter will be passed to Nova along with the port information dictionary. Nova will use this parameter instead of the port binding profile information to command os-vif to create the corresponding layer 1 port (a devlink port [3] [7]).

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 parameter added in this RFE and the port binding profile, that will be added internally by Neutron when the new paramter is not “None”.

  • The second step involves the Nova implementation. This change implies that Nova can read the port new parameter 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-type switchdev port_hwol

The new string field will be visible when showing the port resource.

This spec is not covering the Nova migration from reading the port binding profile to using the new parameter provider in the port definition. As commented in the first section, Neutron will still populate the port binding profile as long as the “hardware-offload-type” is provided in the port creation command. In order to stop users to create a port with the old method, the OSC will check if the “capabilities” key is provided inside the port binding profile and a warning will be printed in the command line, encouraging the user to create the port using the “hardware-offload-type” parameter.

REST API Impact

Proposed attribute:

RESOURCE_ATTRIBUTE_MAP = {
    port.COLLECTION_NAME: {
        "hardware_offload_type": {
            'allow_post': True,
            'allow_put': False,
            'convert_to': converters.convert_to_string,
            'default': None,
            'is_visible': True,
            'is_filter': True,
            'validate': {
                'type:values': constants.VALID_HWOL_TYPES}
        }
    }
}

Sample REST calls:

POST /v2.0/ports
{
    "port": {
       ...
       "hardware_offload_type": "switchdev"
}

Response:
{
    "port": {
        "id": "<id>",
        ...
        "hardware_offload_type": "switchdev"
    }
}

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

CR

Unique identifier for the port object

hardware_offload_type

str

CR

String to indicate the hardware offload type

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 defining this parameter:

policy.DocumentedRuleDefault(
    name='create_port:hardware_offload_type',
    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