yahoo-eng-team team mailing list archive

[sean mooney <smooney@xxxxxxxxxx>]

the device_type is optional but if set it will be checked

https://github.com/openstack/nova/blob/51e3787bf89f19af8a9d37288a63731563c92fca/nova/pci/request.py#L136-L138

type-pci is not intended for fore use with device that are capable of
sriov and exits primarly for use with pci device that are not nics.


type-PCI is reserved for device that will be passthough via the pci aliase in the falvor that should not be request able by neutron based sriov port.

it is generally used for gpus, crypto cards like intel QAT devices or
nics that are not managed by neutron and do not support sriov.

type-PF is use for device that weill be request using neutron vnic_type=direct-physical.
and 
type-VF is used for edvice that eill be requested using neutron vnic_type=direct.

type-pf and type-pf may also be used for non nic device but in that case the physical_network tage must
not be set in the pci whitelist.

when we process a neutron prot we translate form the port vnic type to teh correct device_type here.
https://github.com/openstack/nova/blob/212607dc6feaf311ba92295fd07363b3ee9ae010/nova/network/neutronv2/api.py#L2046-L2060

when enumarting the devices in the libvirt virt dirver here
https://opendev.org/openstack/nova/src/branch/master/nova/virt/libvirt/driver.py#L6076-L6113

we interperat the device capabilities to determine if the which type to
use when reporting the device.

depending on the nic, firmware and and dirver otions the present of the virtual_fucntion capablity in the
pci capablityis reported by libvirt can change.

that is to say on older generation intel nicantics such as the intel 82599 series
the presence of the virtual_fucntion cabpablity was ondition on if data center bridgeing 
was enabled in teh fireware.

in data center bridgeing mode sriov was disabled to allow VMDQ to be used so even with the same vendor and product id
the device type can change.


when a device support sriov and is listed as a PF there are also addtional checks that the schduler and pci resouce tracker must perfrom to determing that a PF is availble for assignemnt to a vm. The most import being the pci resouce track must first confirm that the PF etiher has no VFs or that all VFs are free.

For type-PCI we do not have to do that check as we know it does not
support sriov and thereforce will not have VF that could be in use.



** Changed in: nova
   Importance: Undecided => Wishlist

** Changed in: nova
       Status: New => Opinion

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1832169

Title:
  device_type of PCI alias config could be mismatched

Status in OpenStack Compute (nova):
  Opinion

Bug description:
  Currently, to use PCI passthrough functionality admin should specify
  the alias of PCI devices and the format is like below

  alias = { "vendor_id":"8086", "product_id":"1528", "device_type
  ":"type-PCI", "name":"nic" }

  What I think confusing for this configuration is that there is just
  one "device_type" for the device. I assume that device_type is not
  needed to the device be identified since libvirt made the device_type
  for one device.

  IOW, I suspects it never happens like below.
  alias = { "vendor_id":"8086", "product_id":"1528", "device_type":"type-PCI", "name":"nic" }
  alias = { "vendor_id":"8086", "product_id":"1528", "device_type":"type-PF", "name":"nic" }

  I strongly believe the PCI device having 8086:1528 ID is just already
  set the unique device_type., I'm not 100% sure though.

  So my point is it's better to delete device_type attribute for the
  config so that admin does not care about the device type. I think it's
  big barrier to use PCI passthrough functionality for whom does not
  familiar with the concept.

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1832169/+subscriptions