Open Stack

resending to group instead of to steve..

OK.. Looks like my test results were skewed by strict numa placement policy
set in the flavor, and my neutron ports being created against PCI devices
in a specific NUMA node.
For example, if I use a flavor I suspected of mapping to numa1, and if I
created VFs against PFs in numa1, coupled with strict numa policy, I ended
up using numa1 for cpu, memory and pci locality.

On Fri, Jul 8, 2016 at 12:22 PM, Steve Gordon <sgordon at redhat.com> wrote:

> ----- Original Message -----
> > From: "Brent Troge" <brenttroge2016 at gmail.com>
> > To: openstack at lists.openstack.org
> > Sent: Friday, July 8, 2016 9:59:58 AM
> > Subject: [Openstack] vCPU -> pCPU MAPPING
> >
> > context - high performance private cloud with cpu pinning
> >
> > Is it possible to map vCPUs to specific pCPUs ?
> > Currently I see you can only direct which vCPUs are mapped to a specific
> > NUMA node
> >
> > hw:numa_cpus.0=1,2,3,4
>
> Just in addition to Jay's comment, the above does not do what I suspect
> you think it does. The above tells Nova to expose vCPUs 1, 2, 3, and 4 in
> *guest* NUMA node 0 when building the guest NUMA topology in the Libvirt
> XML. Nova will endeavor to map these vCPUs to pCPUs on the same NUMA node
> on the host as *each other* but that will not necessarily be NUMA node *0*
> on the host depending on resource availability.
>
> Thanks,
>
> Steve
>
> > However, to get even more granular, is it possible to create a flavor
> which
> > maps vCPU to specific pCPU within a numa node ?
> >
> > Something like:
> > hw:numa_cpus.<NUMA-NODE>-<pCPU>=<vCPU>
> >
> > hw:numa_cpus.0-1=1
> > hw:numa_cpus.0-2=2
> >
> >
> > Thanks!
> >
> > _______________________________________________
> > Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to     : openstack at lists.openstack.org
> > Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160708/ab681263/attachment.html>