lp:~dmitriis/+git/nova

Get this repository:
git clone https://git.launchpad.net/~dmitriis/+git/nova
Only Dmitrii Shcherbakov can upload to this repository. If you are Dmitrii Shcherbakov please log in for upload directions.

Branches

Name Last Modified Last Commit
2021-09-10-off-path-net-backends 2021-11-19 07:42:29 UTC
[yoga] Support remote-managed SmartNIC DPU ports

Author: Dmitrii Shcherbakov
Author Date: 2021-09-30 21:56:55 UTC

[yoga] Support remote-managed SmartNIC DPU ports

This change comes as a part of the "Off-path Networking Backends
Support" spec implementation.

https://review.opendev.org/c/openstack/nova-specs/+/787458

Remotely managed VFs need to be classified
as such based on a port type used at port creation. VF logical number
and PF mac also need to be passed to Neutron in port updates to allow
remote_managed ports to be set up correctly on a SmartNIC DPU.

* Add a new PCI whitelist tag called "remote_managed".
  * Ports of VNIC_TYPE_SMARTNIC are managed remotely from a SmartNIC
  DPU's operating system. Operators need a way to specify which devices
  to treat as remotely managed since there is no meta information
  database that would associate vendor and device IDs with the
  information about whether they are remotely managed or not. For that
  purpose, a new PCI device whitelist tag is introduced. By default, it
  is assumed that its value will be False unless overridden explicitly
  in the whitelist specified in a config file. PCI device requests get
  a remote_managed value based on a port type and the logic invoked by
  the PciPassthroughFilter takes care of matching this request value
  against the remote_managed tag obtained from the whitelist
  configuration.

* Include pf mac and vf num in port updates
  * Adds methods to retrieve those at runtime for a VF and include them
  in port updates to Neutron.

* Use the noop os-vif plugin for VNIC_TYPE_SMARTNIC ports in order to
  avoid the invocation of the local representor plugging logic since
  a networking backend is responsible for that in this case.

* Expect bind time events for ports of VNIC_TYPE_SMARTNIC. Events for
  those arrive early from Neutron after a port update (before Nova
  begins to wait in the virt driver code, therefore, Nova is set
  to avoid waiting for plug events for VNIC_TYPE_SMARTNIC ports.

* Make sure the service version is high enough on all compute services
  before creating instances with ports that have VNIC type
  VNIC_TYPE_SMARTNIC. Network requests are examined for the presence of
  port ids to determine the VNIC type via Neutron API. If SmartNIC
  ports are requested, a compute service version check is performed
  across all cells.

Change-Id: I168d3ccc914f25a3d4255c9b319ee6b91a2f66e2
Depends-On: I07ef52769da72cde8867f996111b7df4a80e4d79
Depends-On: I6445433142286728a8c7efadcf80d07082d60bc3

2021-off-path-net-backends 2021-09-09 16:35:58 UTC
Add remote_managed PCI whitelist tag

Author: Dmitrii Shcherbakov
Author Date: 2021-09-09 16:35:58 UTC

Add remote_managed PCI whitelist tag

Ports of VNIC_TYPE_SMARTNIC are managed remotely from a SmartNIC DPU's
operating system. Operators need a way to specify which devices to treat
as remotely managed since there is no meta information database that
would associate vendor and device IDs with the information about whether
they are remotely managed or not. For that purpose, a new PCI device
whitelist tag is introduced. By default, it is assumed that its value
will be False unless overridden explicitly in the whitelist specified in
a config file. PCI device requests get a remote_managed value based on a
port type. PciDevice objects store the remote_managed value in the
extra_info dict if it is present during object creation. Otherwise, the
value is assumed to be False during object-based matching.

Unit tests are modified in this change to account for the added logic.

12 of 2 results
This repository contains Public information 
Everyone can see this information.