Description of problem: Placeholder BZ for multi-queue support for vDPA in OSP. (1) Report the device queue to the db so that it can later be used for scheduling (2) Ensure that the libvirt driver can properly configure multi-queue. the generic code might work but it may need to be adapted to clamp the number of core to min(flavor.cpus, device. queues) (3) Request the number of queues for each device ideally as metadata on the port passed from neutron this may or may not require a neutron change but it could be a new QOS type or similar extension we would then need to modify the scheduler/pci claim code and or placement modeling to accommodate the new resource. (4) Work to track VF and VDPA devices in placement is being done by the community this cycle. while we could do the queue aware scheduling on the nova side eventually it should be modeled in placement somehow, so there would be follow on work to enable that Details to be added based on further invstigation. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
OSP 18 has been feature frozen for several months now. following our RFE request procedure i am converting it to a Jira backlog item for OSP 19. Our jira policy is to not have any feature backlog trackers until after a feature is Released upstream. once the feature is complete upstream we can asses if some of the features is backporable or not to previous OSP releases. The majority of this feature would not be backpoatable even if a minimal subset was. the state fo the RFE can be tracked via https://issues.redhat.com/browse/OSPRH-256 based on the above I'm closing this issue as not a bug.