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.
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.
James should be moving this to VERIFIED in a few days.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Release of components for Red Hat OpenStack Platform 17.0 (Wallaby)), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2022:6543