Support for different NUMA awareness policies for different hardware components

1. Proposed title of this feature request

Support for different NUMA awareness policies for different hardware components

2. What is the nature and description of the request?

Customers have use cases that require different Topology Manager policies for different hardware components, e.g. single-numa-node for CPUs combined with best-effort for NICs

3. Why does the customer need this? (List the business requirements here)

The customer has a 5G RAN guaranteed QoS pod requiring the scheduling of more instances of the pod than can be supported by a single NUMA zone, and therefore requires different instances of pods to be scheduled on different NUMA zones, while:

1. Guaranteeing all CPUs allocated to a single realtime pod come from a single NUMA node (single-numa-node).
2. If possible scheduling a realtime pod onto the same NUMA node as a specific SR-IOV NIC (best-effort).

More details of the customer's use case and requirements and their current workaround are documented here: https://docs.google.com/document/d/1hg8FlUHX36shpfHJx9gdu131FMioza7kzcXKUfboGdk/edit?usp=sharing [Red Hat internal]

In OpenShift 4.12 the customer is using the workaround design documented in the link above. The workaround design has a number of limitations that make it not suitable for long term use.

The customer will be re-architecting their workload/pod such that the current workaround design will no longer work with their new pod architecture which they plan to first use on OpenShift 4.13.

In OpenShift 4.14 (assuming OpenShift 4.13 is already closed to new RFEs) they require the ability to disable topology hinting by the SR-IOV operator.

This could then be combined with a Topology Manager policy of single-numa-node and Topology Manager scope of pod to guarantee all CPUs allocated to the pod come from a single NUMA zone. It would provide no guarantees on which NUMA zone a realtime pod would be scheduled on to and therefore would not address the second requirement.

Beyond OpenShift 4.14 the customer requires a solution that addresses both requirements stated above and described in more detail in the linked document.

4. List any affected packages or components.

• SR-IOV operator
• Topology Manager / CPU Manager / Device Manager