openshift · kquinn1204 · Jan 16, 2026 · Jan 16, 2026 · ocpdocs-vale-bot · Jan 16, 2026
diff --git a/modules/cnf-about-irq-affinity-setting.adoc b/modules/cnf-about-irq-affinity-setting.adoc
@@ -7,6 +7,7 @@
 [id="about_irq_affinity_setting_{context}"]
 = Finding the effective IRQ affinity setting for a node
 
+[role="_abstract"]
 Some IRQ controllers lack support for IRQ affinity setting and will always expose all online CPUs as the IRQ mask. These IRQ controllers effectively run on CPU 0.
 
 The following are examples of drivers and hardware that Red Hat are aware lack support for IRQ affinity setting. The list is, by no means, exhaustive:

diff --git a/modules/cnf-about-the-profile-creator-tool.adoc b/modules/cnf-about-the-profile-creator-tool.adoc
@@ -6,6 +6,7 @@
 [id="cnf-about-the-profile-creator-tool_{context}"]
 = About the Performance Profile Creator
 
+[role="_abstract"]
 The Performance Profile Creator (PPC) is a command-line tool, delivered with the Node Tuning Operator, that can help you to create a performance profile for your cluster.
 
 Initially, you can use the PPC tool to process the `must-gather` data to display key performance configurations for your cluster, including the following information:
@@ -15,7 +16,6 @@ Initially, you can use the PPC tool to process the `must-gather` data to display
 
 You can use this information to help you configure the performance profile.
 
-.Running the PPC
 Specify performance configuration arguments to the PPC tool to generate a proposed performance profile that is appropriate for your hardware, topology, and use-case.
 
 You can run the PPC by using one of the following methods:

diff --git a/modules/cnf-adjusting-nic-queues-with-the-performance-profile.adoc b/modules/cnf-adjusting-nic-queues-with-the-performance-profile.adoc
@@ -6,6 +6,7 @@
 [id="adjusting-nic-queues-with-the-performance-profile_{context}"]
 = Adjusting the NIC queues with the performance profile
 
+[role="_abstract"]
 The performance profile lets you adjust the queue count for each network device.
 
 Supported network devices:

diff --git a/modules/cnf-allocating-multiple-huge-page-sizes.adoc b/modules/cnf-allocating-multiple-huge-page-sizes.adoc
@@ -3,9 +3,12 @@
 // * scalability_and_performance/cnf-low-latency-tuning.adoc
 // * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
 
+:_mod-docs-content-type: CONCEPT
+
 [id="cnf-allocating-multiple-huge-page-sizes_{context}"]
 = Allocating multiple huge page sizes
 
+[role="_abstract"]
 You can request huge pages with different sizes under the same container. This allows you to define more complicated pods consisting of containers with different huge page size needs.
 
 For example, you can define sizes `1G` and `2M` and the Node Tuning Operator will configure both sizes on the node, as shown here:

diff --git a/modules/cnf-configure_for_irq_dynamic_load_balancing.adoc b/modules/cnf-configure_for_irq_dynamic_load_balancing.adoc
@@ -6,6 +6,7 @@
 [id="configuring_for_irq_dynamic_load_balancing_{context}"]
 = Configuring node interrupt affinity
 
+[role="_abstract"]
 Configure a cluster node for IRQ dynamic load balancing to control which cores can receive device interrupt requests (IRQ).
 
 .Prerequisites

diff --git a/modules/cnf-configuring-huge-pages.adoc b/modules/cnf-configuring-huge-pages.adoc
@@ -3,14 +3,18 @@
 // * scalability_and_performance/cnf-low-latency-tuning.adoc
 // * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
 
+:_mod-docs-content-type: PROCEDURE
 [id="cnf-configuring-huge-pages_{context}"]
 = Configuring huge pages
 
+[role="_abstract"]
 Nodes must pre-allocate huge pages used in an {product-title} cluster. Use the Node Tuning Operator to allocate huge pages on a specific node.
 
 {product-title} provides a method for creating and allocating huge pages. Node Tuning Operator provides an easier method for doing  this using the performance profile.
 
-For example, in the `hugepages` `pages` section of the performance profile, you can specify multiple blocks of `size`, `count`, and, optionally, `node`:
+.Procedure
+
+. In the `hugepages` `pages` section of the performance profile, specify blocks of `size`, `count`, and, optionally, `node`:
 
 [source,yaml]
 ----
@@ -19,11 +23,10 @@ hugepages:
    pages:
    - size:  "1G"
      count:  4
-     node:  0 <1>
+     # node is the NUMA node in which the huge pages are allocated. If you omit node, the pages are evenly spread across all NUMA nodes.
+     node:  0
 ----
-
-<1> `node` is the NUMA node in which the huge pages are allocated. If you omit `node`, the pages are evenly spread across all NUMA nodes.
-
++
 [NOTE]
 ====
 Wait for the relevant machine config pool status that indicates the update is finished.

diff --git a/modules/cnf-configuring-hyperthreading-for-a-cluster.adoc b/modules/cnf-configuring-hyperthreading-for-a-cluster.adoc
@@ -6,6 +6,7 @@
 [id="cnf-configuring-hyperthreading-for-a-cluster_{context}"]
 = Configuring Hyper-Threading for a cluster
 
+[role="_abstract"]
 To configure Hyper-Threading for an {product-title} cluster, set the CPU threads in the performance profile to the same cores that are configured for the reserved or isolated CPU pools.
 
 [NOTE]
@@ -80,7 +81,7 @@ $ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
 ====
 The reserved and isolated CPU pools must not overlap and together must span all available cores in the worker node.
 ====
-
++
 [IMPORTANT]
 ====
 Hyper-Threading is enabled by default on most Intel processors. If you enable Hyper-Threading, all threads processed by a particular core must be isolated or processed on the same core.
@@ -89,13 +90,7 @@ When Hyper-Threading is enabled, all guaranteed pods must use multiples of the s
 See link:https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#static-policy-options[Static policy options] for more information.
 ====
 
-[id="disabling_hyperthreading_for_low_latency_applications_{context}"]
-== Disabling Hyper-Threading for low latency applications
-
-When configuring clusters for low latency processing, consider whether you want to disable Hyper-Threading before you deploy the cluster. To disable Hyper-Threading, perform the following steps:
-
-. Create a performance profile that is appropriate for your hardware and topology.
-. Set `nosmt` as an additional kernel argument. The following example performance profile illustrates this setting:
+. Optional: To disable Hyper-Threading for low latency applications, set `nosmt` as an additional kernel argument in the performance profile. The following example performance profile illustrates this setting:
 +
 [source,yaml]
 ----

diff --git a/modules/cnf-configuring-power-saving-for-nodes.adoc b/modules/cnf-configuring-power-saving-for-nodes.adoc
@@ -6,6 +6,7 @@
 [id="cnf-configuring-power-saving-for-nodes_{context}"]
 = Configuring power saving for nodes that run colocated high and low priority workloads
 
+[role="_abstract"]
 You can enable power savings for a node that has low priority workloads that are colocated with high priority workloads without impacting the latency or throughput of the high priority workloads. Power saving is possible without modifications to the workloads themselves.
 
 [IMPORTANT]

diff --git a/modules/cnf-configuring-workload-hints.adoc b/modules/cnf-configuring-workload-hints.adoc
@@ -17,6 +17,7 @@
 |Performance Profile creator setting |Hint |Environment |Description
 
 |Default
+[role="_abstract"]
 a|[source,terminal]
 ----
 workloadHints:

diff --git a/modules/cnf-cpu-infra-container.adoc b/modules/cnf-cpu-infra-container.adoc
@@ -7,6 +7,7 @@
 [id="cnf-cpu-infra-container_{context}"]
 = Restricting CPUs for infra and application containers
 
+[role="_abstract"]
 Generic housekeeping and workload tasks use CPUs in a way that may impact latency-sensitive processes. By default, the container runtime uses all online CPUs to run all containers together, which can result in context switches and spikes in latency. Partitioning the CPUs prevents noisy processes from interfering with latency-sensitive processes by separating them from each other. The following table describes how processes run on a CPU after you have tuned the node using the Node Tuning Operator:
 
 .Process' CPU assignments
@@ -36,11 +37,9 @@ Generic housekeeping and workload tasks use CPUs in a way that may impact latenc
 
 The allocatable capacity of cores on a node for pods of all QoS process types, `Burstable`,  `BestEffort`, or `Guaranteed`, is equal to the capacity of the isolated pool. The capacity of the reserved pool is removed from the node's total core capacity for use by the cluster and operating system housekeeping duties.
 
-.Example 1
-A node features a capacity of 100 cores. Using a performance profile, the cluster administrator allocates 50 cores to the isolated pool and 50 cores to the reserved pool. The cluster administrator assigns 25 cores to QoS `Guaranteed` pods and 25 cores for `BestEffort` or `Burstable` pods. This matches the capacity of the isolated pool.
+For example, a node features a capacity of 100 cores. Using a performance profile, the cluster administrator allocates 50 cores to the isolated pool and 50 cores to the reserved pool. The cluster administrator assigns 25 cores to QoS `Guaranteed` pods and 25 cores for `BestEffort` or `Burstable` pods. This matches the capacity of the isolated pool.
 
-.Example 2
-A node features a capacity of 100 cores. Using a performance profile, the cluster administrator allocates 50 cores to the isolated pool and 50 cores to the reserved pool. The cluster administrator assigns 50 cores to QoS `Guaranteed` pods and one core for `BestEffort` or `Burstable` pods. This exceeds the capacity of the isolated pool by one core. Pod scheduling fails because of insufficient CPU capacity.
+However, if the cluster administrator assigns 50 cores to QoS `Guaranteed` pods and one core for `BestEffort` or `Burstable` pods, this exceeds the capacity of the isolated pool by one core. Pod scheduling fails because of insufficient CPU capacity.
 
 
 The exact partitioning pattern to use depends on many factors like hardware, workload characteristics and the expected system load. Some sample use cases are as follows:
@@ -76,11 +75,11 @@ metadata:
   name: infra-cpus
 spec:
   cpu:
-    reserved: "0-4,9" <1>
-    isolated: "5-8" <2>
-  nodeSelector: <3>
+    # Specify which CPUs are for infra containers to perform cluster and operating system housekeeping duties.
+    reserved: "0-4,9"
+    # Specify which CPUs are for application containers to run workloads.
+    isolated: "5-8"
+  # Optional: Specify a node selector to apply the performance profile to specific nodes.
+  nodeSelector:
     node-role.kubernetes.io/worker: ""
 ----
-<1> Specify which CPUs are for infra containers to perform cluster and operating system housekeeping duties.
-<2> Specify which CPUs are for application containers to run workloads.
-<3> Optional: Specify a node selector to apply the performance profile to specific nodes.
diff --git a/modules/cnf-creating-mcp-for-ppc.adoc b/modules/cnf-creating-mcp-for-ppc.adoc
@@ -6,6 +6,7 @@
 [id="creating-mcp-for-ppc_{context}"]
 = Creating a machine config pool to target nodes for performance tuning
 
+[role="_abstract"]
 For multi-node clusters, you can define a machine config pool (MCP) to identify the target nodes that you want to configure with a performance profile. 
 
 In {sno} clusters, you must use the `master` MCP because there is only one node in the cluster. You do not need to create a separate MCP for {sno} clusters.
@@ -21,9 +22,9 @@ In {sno} clusters, you must use the `master` MCP because there is only one node
 +
 [source,terminal]
 ----
-$ oc label node <node_name> node-role.kubernetes.io/worker-cnf="" <1>
+# Replace `<node_name>` with the name of your node. This example applies the `worker-cnf` label.
+$ oc label node <node_name> node-role.kubernetes.io/worker-cnf=""
 ----
-<1> Replace `<node_name>` with the name of your node. This example applies the `worker-cnf` label.
 
 . Create a `MachineConfigPool` resource containing the target nodes:
 
@@ -35,9 +36,11 @@ $ oc label node <node_name> node-role.kubernetes.io/worker-cnf="" <1>
 apiVersion: machineconfiguration.openshift.io/v1
 kind: MachineConfigPool
 metadata:
-  name: worker-cnf <1>
+  # Specify a name for the `MachineConfigPool` resource.
+  name: worker-cnf
   labels:
-    machineconfiguration.openshift.io/role: worker-cnf <2>
+    # Specify a unique label for the machine config pool.
+    machineconfiguration.openshift.io/role: worker-cnf
 spec:
   machineConfigSelector:
     matchExpressions:
@@ -49,11 +52,9 @@ spec:
   paused: false
   nodeSelector:
     matchLabels:
-      node-role.kubernetes.io/worker-cnf: "" <3>
+      # Specify the nodes with the target label that you defined.
+      node-role.kubernetes.io/worker-cnf: ""
 ----
-<1> Specify a name for the `MachineConfigPool` resource.
-<2> Specify a unique label for the machine config pool.
-<3> Specify the nodes with the target label that you defined.
 
 .. Apply the `MachineConfigPool` resource by running the following command:
 +
@@ -84,4 +85,4 @@ NAME         CONFIG                                                 UPDATED   UP
 master       rendered-master-58433c7c3c1b4ed5ffef95234d451490       True      False      False      3              3                   3                     0                      6h46m
 worker       rendered-worker-168f52b168f151e4f853259729b6azc4       True      False      False      2              2                   2                     0                      6h46m
 worker-cnf   rendered-worker-cnf-168f52b168f151e4f853259729b6azc4   True      False      False      1              1                   1                     0                      73s
-----
+----
diff --git a/modules/cnf-gathering-data-about-cluster-using-must-gather.adoc b/modules/cnf-gathering-data-about-cluster-using-must-gather.adoc
@@ -6,6 +6,7 @@
 [id="gathering-data-about-your-cluster-using-must-gather_{context}"]
 = Gathering data about your cluster for the PPC
 
+[role="_abstract"]
 The Performance Profile Creator (PPC) tool requires `must-gather` data. As a cluster administrator, run the `must-gather` command to capture information about your cluster.
 
 .Prerequisites

diff --git a/modules/cnf-logging-associated-with-adjusting-nic-queues.adoc b/modules/cnf-logging-associated-with-adjusting-nic-queues.adoc
@@ -2,9 +2,12 @@
 //
 // * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
 
+:_mod-docs-content-type: REFERENCE
+
 [id="logging-associated-with-adjusting-nic-queues_{context}"]
 = Logging associated with adjusting NIC queues
 
+[role="_abstract"]
 Log messages detailing the assigned devices are recorded in the respective Tuned daemon logs. The following messages might be recorded to the `/var/log/tuned/tuned.log` file:
 
 * An `INFO` message is recorded detailing the successfully assigned devices:

diff --git a/.../cnf-managing-device-interrupt-processing-for-guaranteed-pod-isolated-cpus.adoc b/.../cnf-managing-device-interrupt-processing-for-guaranteed-pod-isolated-cpus.adoc
@@ -2,9 +2,12 @@
 //
 // * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
 
+:_mod-docs-content-type: CONCEPT
+
 [id="managing-device-interrupt-processing-for-guaranteed-pod-isolated-cpus_{context}"]
 = Managing device interrupt processing for guaranteed pod isolated CPUs
 
+[role="_abstract"]
 The Node Tuning Operator can manage host CPUs by dividing them into reserved CPUs for cluster and operating system housekeeping duties, including pod infra containers, and isolated CPUs for application containers to run the workloads. This allows you to set CPUs for low latency workloads as isolated.
 
 Device interrupts are load balanced between all isolated and reserved CPUs to avoid CPUs being overloaded, with the exception of CPUs where there is a guaranteed pod running. Guaranteed pod CPUs are prevented from processing device interrupts when the relevant annotations are set for the pod.

diff --git a/modules/cnf-memory-optimization.adoc b/modules/cnf-memory-optimization.adoc
@@ -6,4 +6,5 @@
 [id="cnf-configuring-kernal-page-size_{context}"]
 = Configuring memory page sizes
 
-By configuring memory page sizes, system administrators can implement more efficient memory management on a specific node to suit workload requirements. The Node Tuning Operator provides a method for configuring huge pages and kernel page sizes by using a performance profile.
+[role="_abstract"]
+By configuring memory page sizes, system administrators can implement more efficient memory management on a specific node to suit workload requirements. The Node Tuning Operator provides a method for configuring huge pages and kernel page sizes by using a performance profile.
diff --git a/modules/cnf-performance-profile-creator-arguments.adoc b/modules/cnf-performance-profile-creator-arguments.adoc
@@ -2,7 +2,7 @@
 //
 // * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
 
-
+:_mod-docs-content-type: REFERENCE
 [id="performance-profile-creator-arguments_{context}"]
 = Performance Profile Creator arguments
 
@@ -17,6 +17,7 @@
 | `must-gather-dir-path`
 | The path of the must gather directory.
 
+[role="_abstract"]
 This argument is only required if you run the PPC tool by using Podman. If you use the PPC with the wrapper script, do not use this argument. Instead, specify the directory path to the `must-gather` tarball by using the `-t` option for the wrapper script.
 
 | `reserved-cpu-count`
@@ -129,4 +130,4 @@ Default: `restricted`.
 Possible values: `true` or `false`.
 
 Default: `false`.
-|===
+|===
diff --git a/modules/cnf-running-the-performance-creator-profile-offline.adoc b/modules/cnf-running-the-performance-creator-profile-offline.adoc
@@ -6,6 +6,7 @@
 [id="running-the-performance-profile-creator-wrapper-script_{context}"]
 = Running the Performance Profile Creator wrapper script
 
+[role="_abstract"]
 The wrapper script simplifies the process of creating a performance profile with the Performance Profile Creator (PPC) tool. The script handles tasks such as pulling and running the required container image, mounting directories into the container, and providing parameters directly to the container through Podman.
 
 For more information about the Performance Profile Creator arguments, see the section _"Performance Profile Creator arguments"_.

diff --git a/modules/cnf-running-the-performance-creator-profile.adoc b/modules/cnf-running-the-performance-creator-profile.adoc
@@ -6,6 +6,7 @@
 [id="running-the-performance-profile-profile-cluster-using-podman_{context}"]
 = Running the Performance Profile Creator using Podman
 
+[role="_abstract"]
 As a cluster administrator, you can use Podman with the Performance Profile Creator (PPC) to create a performance profile.
 
 For more information about the PPC arguments, see the section _"Performance Profile Creator arguments"_.

diff --git a/modules/cnf-telco-core-reference-design-performance-profile-template.adoc b/modules/cnf-telco-core-reference-design-performance-profile-template.adoc
@@ -6,6 +6,7 @@
 [id="cnf-telco-core-reference-design-performance-profile-template_{context}"]
 = Telco core reference design performance profile
 
+[role="_abstract"]
 The following performance profile configures node-level performance settings for {product-title} clusters on commodity hardware to host telco core workloads.
 
 .Telco core reference design performance profile

diff --git a/modules/cnf-telco-ran-reference-design-performance-profile-template.adoc b/modules/cnf-telco-ran-reference-design-performance-profile-template.adoc
@@ -6,6 +6,7 @@
 [id="cnf-telco-ran-reference-design-performance-profile-template_{context}"]
 = Telco RAN DU reference design performance profile
 
+[role="_abstract"]
 The following performance profile configures node-level performance settings for {product-title} clusters on commodity hardware to host telco RAN DU workloads.
 
 .Telco RAN DU reference design performance profile

diff --git a/modules/cnf-use-device-interrupt-processing-for-isolated-cpus.adoc b/modules/cnf-use-device-interrupt-processing-for-isolated-cpus.adoc
@@ -3,9 +3,12 @@
 // * scalability_and_performance/low_latency_tuning/cnf-provisioning-low-latency-workloads.adoc
 // * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
 
+:_mod-docs-content-type: CONCEPT
+
 [id="nto_supported_api_versions_{context}"]
 = Supported performance profile API versions
 
+[role="_abstract"]
 The Node Tuning Operator supports `v2`, `v1`, and `v1alpha1` for the performance profile `apiVersion` field. The v1 and v1alpha1 APIs are identical. The v2 API includes an optional boolean field `globallyDisableIrqLoadBalancing` with a default value of `false`.
 
 [discrete]

diff --git a/modules/cnf-verifying-queue-status.adoc b/modules/cnf-verifying-queue-status.adoc
@@ -2,9 +2,12 @@
 //
 // * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
 
+:_mod-docs-content-type: PROCEDURE
+
 [id="verifying-queue-status_{context}"]
 = Verifying the queue status
 
+[role="_abstract"]
 In this section, a number of examples illustrate different performance profiles and how to verify the changes are applied.
 
 .Example 1