Bug 1727658

Summary:	[RFE] Nova & Neutron support for Intel Speed Shift Technology Base Frequency
Product:	Red Hat OpenStack	Reporter:	arkady kanevsky <arkady_kanevsky>
Component:	openstack-nova	Assignee:	OSP DFG:Compute <osp-dfg-compute>
Status:	CLOSED DUPLICATE	QA Contact:	OSP DFG:Compute <osp-dfg-compute>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	16.0 (Train)	CC:	christopher_dearborn, dasmith, egallen, eglynn, fbaudin, gael_rehault, jhakimra, kchamart, kholtz, kurt_hey, mbooth, morazi, rajini.karthik, sbauza, scohen, sgordon, stephenfin, vromanso
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-09-29 09:53:12 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:
Bug Depends On:	1703188, 1720208
Bug Blocks:	1667921, 1718945

Description arkady kanevsky 2019-07-07 22:43:50 UTC

Description of problem:
New Intel Cascade lake has improvements for optimized for NFV workloads.
That includes SST-PP,  SST- BF and SST-CP.

Spec for Placement for NOVA https://review.opendev.org/#/c/555081/ starts to address it but falls short.
It will need to be extended to handle SST- BF.
First the idea of the physical core frequency need to be added, since SKU-N processors have different cores of different frequency on the same processor.
Not sure if it has to be also extended for hyperthreaded cores.  I think for NFV workloads cores will be dedicated without over subscription.
I think if one describes node core resources in sets of cores of different speed it will work.  But then a scheduler can only schedule NFV (or other) workloads to only cores from the same set.
This basically will do NUMA pinning using flavor.
The same placement ideas with all its details will need to be extended to migration, live and cold.
And for NFV workloads it will have to extended to neutron to have dedicated PF on physical NIC ports on the same node where SKU-N cores are allocated.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 smooney 2019-07-12 13:55:46 UTC

https://review.opendev.org/#/c/555081/  is intentionally not trying to support this usecase.

however it can be missued to do so.

https://review.opendev.org/#/c/555081/  changes how we declare cpus in the nova.conf
going forward we will use 2 cpus set. cpu_dedicated_set and cpu_shared_set.

if you map the cpu_dedicated_set to the high frequency core and map cpu_shared_set to 
the low frequency cores then you can optimise fo the use of SST-BF.
the cpu_shared_set will allow you to optional over subscribe your low frequency cores
wile the high frequency core will have no over subsction.

we are discussing this feature with intel to understand if an how we would extend
nova to support this in a more dynamic way but for OSP 16 we do not intend to add explcit
support beyond what i discribed above.

nova already create a numa toplogy when you enable cpu pinning.
if a guest has a numa toplogy nova enforces numa affinity to the same numa node when
passing through sriov devieces we also have a feature called numa aware vswitchs so no
work is need in neutron for numa affintiy of nics.

numa aware live migration is also in flight for OSP 16 which should close
the gap in that respect so assuming both the numa aware live migrtaion lands
and the cpu track in placment feature lands in upstream Train the gaps you identifed should
be adressed.

Comment 3 Erwan Gallen 2020-09-29 09:53:12 UTC


*** This bug has been marked as a duplicate of bug 1793700 ***