mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
f45e35cf82
Jeana's comments Update modules/telco-ran-gitops-operator-and-ztp-plugins.adoc Co-authored-by: Alex Dellapenta <adellape@redhat.com> Update modules/telco-ran-gitops-operator-and-ztp-plugins.adoc Co-authored-by: Alex Dellapenta <adellape@redhat.com> Update modules/telco-ran-gitops-operator-and-ztp-plugins.adoc Co-authored-by: Alex Dellapenta <adellape@redhat.com> Update modules/telco-ran-bios-tuning.adoc Co-authored-by: Alex Dellapenta <adellape@redhat.com> Update modules/telco-ran-gitops-operator-and-ztp-plugins.adoc Co-authored-by: Alex Dellapenta <adellape@redhat.com> Update modules/telco-ran-lvms-operator.adoc Co-authored-by: Alex Dellapenta <adellape@redhat.com> Update modules/telco-ran-local-storage-operator.adoc Co-authored-by: Alex Dellapenta <adellape@redhat.com> Update modules/telco-ran-ptp-operator.adoc Co-authored-by: Alex Dellapenta <adellape@redhat.com> Update modules/telco-ran-lca-operator.adoc Co-authored-by: Alex Dellapenta <adellape@redhat.com> Update modules/telco-ran-lvms-operator.adoc Co-authored-by: Alex Dellapenta <adellape@redhat.com> Update modules/telco-ran-sr-iov-operator.adoc Co-authored-by: Alex Dellapenta <adellape@redhat.com> Update modules/telco-ran-sr-iov-operator.adoc Co-authored-by: Alex Dellapenta <adellape@redhat.com> review fixes final review comments for RAN RDS 418 Sharat's ClusterInstance updates Ian's comments
53 lines
3.0 KiB
Plaintext
53 lines
3.0 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
|
|
|
|
:_mod-docs-content-type: REFERENCE
|
|
[id="telco-ran-node-tuning-operator_{context}"]
|
|
= CPU partitioning and performance tuning
|
|
|
|
New in this release::
|
|
* No reference design updates in this release
|
|
|
|
Description::
|
|
The RAN DU use model includes cluster performance tuning via `PerformanceProfile` CRs for low-latency performance.
|
|
The `PerformanceProfile` CRs are reconciled by the Node Tuning Operator.
|
|
The RAN DU use case requires the cluster to be tuned for low-latency performance.
|
|
For more details about node tuning with the `PerformanceProfile` CR, see "Tuning nodes for low latency with the performance profile".
|
|
|
|
Limits and requirements::
|
|
The Node Tuning Operator uses the `PerformanceProfile` CR to configure the cluster.
|
|
You need to configure the following settings in the telco RAN DU profile `PerformanceProfile` CR:
|
|
+
|
|
--
|
|
* Set a reserved `cpuset` of 4 or more, equating to 4 hyper-threads (2 cores) for either of the following CPUs:
|
|
** Intel 3rd Generation Xeon (IceLake) 2.20 GHz or better CPUs with host firmware tuned for maximum performance
|
|
** AMD EPYC Zen 4 CPUs (Genoa, Bergamo, or newer)
|
|
+
|
|
[NOTE]
|
|
====
|
|
AMD EPYC Zen 4 CPUs (Genoa, Bergamo, or newer) are fully supported.
|
|
Power consumption evaluations are ongoing.
|
|
It is recommended to evaluate features, such as per-pod power management, to determine any potential impact on performance.
|
|
====
|
|
|
|
* Set the reserved `cpuset` to include both hyper-thread siblings for each included core.
|
|
Unreserved cores are available as allocatable CPU for scheduling workloads.
|
|
* Ensure that hyper-thread siblings are not split across reserved and isolated cores.
|
|
* Ensure that reserved and isolated CPUs include all the threads for all cores in the CPU.
|
|
* Include Core 0 for each NUMA node in the reserved CPU set.
|
|
* Set the huge page size to 1G.
|
|
* Only pin {product-title} pods which are by default configured as part of the management workload partition to reserved cores.
|
|
--
|
|
|
|
Engineering considerations::
|
|
* Meeting the full performance metrics requires use of the RT kernel.
|
|
If required, you can use the non-RT kernel with corresponding impact to performance.
|
|
* The number of hugepages you configure depends on application workload requirements.
|
|
Variation in this parameter is expected and allowed.
|
|
* Variation is expected in the configuration of reserved and isolated CPU sets based on selected hardware and additional components in use on the system.
|
|
The variation must still meet the specified limits.
|
|
* Hardware without IRQ affinity support affects isolated CPUs.
|
|
To ensure that pods with guaranteed whole CPU QoS have full use of allocated CPUs, all hardware in the server must support IRQ affinity.
|
|
* When workload partitioning is enabled by setting `cpuPartitioningMode` to `AllNodes` during deployment, you must allocate enough CPUs to support the operating system, interrupts, and {product-title} pods in the `PerformanceProfile` CR.
|