device_type of PCI alias config could be mismatched

[Yang Youseok]

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.

[sean mooney (sean-k-mooney)]

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.

[sean mooney (sean-k-mooney)]

i should also note that some dirver like hyperv only use
type-pci
https://opendev.org/openstack/nova/src/branch/master/nova/virt/hyperv/hostops.py#L192-L215

class PciDeviceType(BaseNovaEnum):

    # NOTE(jaypipes): It's silly that the word "type-" is in these constants,
    # but alas, these were the original constant strings used...
    STANDARD = "type-PCI"
    SRIOV_PF = "type-PF"
    SRIOV_VF = "type-VF"

    ALL = (STANDARD, SRIOV_PF, SRIOV_VF)

https://opendev.org/openstack/nova/src/branch/master/nova/objects/fields.py#L681-L689

[Yang Youseok (ileixe)]

@sean Thanks for further explanation. I do realized there could be different device type for one device and it's required. This report is due to the lack of my SR-IOV background so I changed the status to invalid. I think it's enough to add more story about device_type in documentation.

Thanks.