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:
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.
*** This bug has been marked as a duplicate of bug 1793700 ***