Bug 2224454

Summary:	Multi-queue support for vDPA
Product:	Red Hat OpenStack	Reporter:	Gurpreet Singh <gurpsing>
Component:	openstack-nova	Assignee:	smooney
Status:	CLOSED NOTABUG	QA Contact:	OSP DFG:Compute <osp-dfg-compute>
Severity:	high	Docs Contact:
Priority:	high
Version:	17.1 (Wallaby)	CC:	dasmith, eglynn, jhakimra, kchamart, sbauza, sgordon, vromanso
Target Milestone:	ga
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-07-26 13:00:02 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gurpreet Singh 2023-07-20 23:06:13 UTC

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:

Comment 2 smooney 2023-07-26 13:00:02 UTC

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.