Bug 1467442 - RFE: Nova needs to be aware of NUMA locality of physical NICS when plugging instance DPDK VIFS from Neutron Networks
Summary: RFE: Nova needs to be aware of NUMA locality of physical NICS when plugging i...
Keywords:
Status: CLOSED DUPLICATE of bug 1187945
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova
Version: 11.0 (Ocata)
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: Eoghan Glynn
QA Contact: Joe H. Rahme
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-03 22:55 UTC by Chris Paquin
Modified: 2022-03-13 14:20 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-18 20:38:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Chris Paquin 2017-07-03 22:55:21 UTC
Description of problem: Nova is not aware NUMA locality of physical NICs when launching a nova instance. For example, when creating an instance nova attempts to pin the instance to a particular NUMA node, however nova is not aware of the locallity of the DPDK enables interfaces and will launch and instance pinned to a particular numa node, even if the virtual nic is local to a different NUMA node.

Because of this proper DKDP tuning requires all interfaces (bonded or not) to be in same NUMA node, and your NovaPinSet must only specify cores from one NUMA node.


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


How reproducible:
Via director, deploy OSP 11 and configure two DPDK enabled interfaces, one local to each NUMA node on a Compute Node.  Configure NovaPinSet to include cores from each NUMA node. Create network port and launch an instance. Nova is not aware of NUMA locality of the DPDK interfaces and can pin an instance to a NUMA node that is not local to the Network Interface


Actual results:

New Instance can be pinned to cores in one NUMA node, and its VIF can be local to another NUMA node.  



Expected results:

Ideally one should be able to include cores from both CPUs (NUMA nodes) and when an instance is launched Nova looks at the NUMA locality of the network and isolates the instance to the correct NUMA node.




Additional info:


Furthermore, In dual socket systems, the only way to ensure that a Nova instance does not cross NUMA boundaries is to set the NovaPinSet to use only the cores from one physical CPUs. The cores from the second NUMA node will have to remain unused by Nova to ensure proper NUMA allignment. 

Note that this configuration will require a DPDK enabled interfaces attached to two separate networks. One network/interface for NUMA node 0 pinned instances, and one network/interface for NUMA node 1 pinned instances. I do not think that it will be possible to bond interfaces in dispirit NUMA nodes due to how network traffic will be routed back to the Compute host when only one network is presented externally.

Comment 1 Chris Paquin 2017-07-03 22:57:50 UTC
Note that there is an old BZ that requests NUMA awareness for Nova, but is not specific to DPDK[1]. I was unsure if this RFE would be considered a duplicate of that BZ, since this request is specific to OVS-DPDK



[1] https://bugzilla.redhat.com//show_bug.cgi?id=1187945

Comment 2 Stephen Gordon 2017-07-11 14:45:26 UTC
Similar to https://bugzilla.redhat.com//show_bug.cgi?id=1187945#c21 we do not have enough information in the scheduler to make such a placement decision. We would need more information from OVS-DPDK and Neutron, probably associated with the port, to make such placement call.

Also to me this presents as a duplicate of Bug # 1187945, as regardless of whether OVS or OVS-DPDK is on the other side Nova needs similar information and the placement being requested is identical (place on same NUMA node as the NIC backing the VIF).

Comment 3 Stephen Gordon 2017-07-18 20:38:18 UTC

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


Note You need to log in before you can comment on or make changes to this bug.