This BZ track the neutron change to support Optional NUMA affinity for neutron ports and is the sibling of https://bugzilla.redhat.com/show_bug.cgi?id=1780721 which tracks the nova changes. +++ This bug was initially created as a clone of Bug #1780721 +++ Nova supports numa affinity for instance based on device passthough, cpu pinning and hugepages. in recent release numa affinity of generic neutron networks was introduced. In current release when the numa aware vswitch feature is used strict numa affinity is require between the neutron network and the guest. As numa aware vswitch is a host wide configuration this can lead to sub optimal utilization as strict affinity is not require for all guests. This RFE suggests introducing a new per port numa affinity policy which will allow end user to express there affinity requirement in a more granular way. initially it is proposed to model this policy as a neutron qos policy so that control of the creation of numa affinity polices reside with the admin but tenant can freely choose form the admin created policies and apply them to ports. this policy shoudl apply to both sriov interface and the numa aware vswitch feature. --- Additional comment from on 2019-12-06 18:08:14 UTC --- previous notes regarding this from denver ptg can be found here on line 16 https://etherpad.openstack.org/p/ptg-train-xproj-nova-neutron i will file an upstream neutron rfe bug next week and update the BZ. i am open to changes in the design form a neutron point of view but the main requirements are to be able to express a policy for numa affinity per port which will apply to all port vnic types. e.g. this shoudl work for sriov, hardware offloaded ovs or ovn with nova's numa aware vswitchs feature. it is intended to require no change to neutron beyond the storage of the policy so no modification to the sriov nic agent, ovn or neutron ovs agent should be required outside of supporting the qos policy to be applied to the port. an alternative would be to add a new api extension specifically for numa affinity but that is a more intrusive change and since each qos policy has an extension anyway it will not change discoverablity. i will try to follow up with folk but upstream and down stream next week or in early January as i will not be actively working on it until after i return form pto. --- Additional comment from on 2019-12-06 18:12:53 UTC --- setting a dev nack upstream untill we get approval of the rfe by the neutron folks but i think the idea in general has been signed off on before so other then the technical details and userablity i dont see a significant blocker to this in principal. --- Additional comment from RHEL Program Management on 2020-01-15 13:03:33 UTC --- Since this bug report now has devel_ack+, the Devel Conditional NAK state is no longer valid and has been cleared.