TELCODOCS-1990: Docfooding feedback openshift#1 applied

TELCODOCS-1990: Docfooding feedback openshift#2 applied

TELCODOCS-1990: Docfooding feedback openshift#3 applied

TELCODOCS-1990: Docfooding feedback openshift#4 applied

TELCODOCS-1990: Docfooding feedback openshift#5 applied

TELCODOCS-1990: Docfooding feedback openshift#6 applied

TELCODOCS-1990: Docfooding feedback openshift#7 applied

TELCODOCS-1990: Docfooding feedback openshift#8 applied

TELCODOCS-1990: Docfooding feedback openshift#9 applied

TELCODOCS-1990: Docfooding feedback openshift#10 applied

TELCODOCS-1990: Docfooding feedback openshift#11 applied

TELCODOCS-1990: Peer review feedback applied

TELCODOCS-1990: Dev review feedback applied

TELCODOCS-1990: Dev/Peer review feedback applied

TELCODOCS-1990: Dev/Peer openshift#2 review feedback applied

TELCODOCS-1990: Dev openshift#2 review feedback applied

modules/cnf-performing-end-to-end-tests-running-cyclictest.adoc

@@ -10,16 +10,12 @@ The `cyclictest` tool measures the real-time kernel scheduler latency on the spe
 
 [NOTE]
 ====
-When executing `podman` commands as a non-root or non-privileged user, mounting paths can fail with `permission denied` errors. To make the `podman` command work, append `:Z` to the volumes creation; for example, `-v $(pwd)/:/kubeconfig:Z`. This allows `podman` to do the proper SELinux relabeling.
+When executing `podman` commands as a non-root or non-privileged user, mounting paths can fail with `permission denied` errors. Depending on your local operating system and SELinux configuration, you might also experience issues running these commands from your home directory. To make the `podman` commands work, run the commands from a folder that is not your home/<username> directory, and append `:Z` to the volumes creation. For example, `-v $(pwd)/:/kubeconfig:Z`. This allows `podman` to do the proper SELinux relabeling.
 ====
 
 .Prerequisites
 
-* You have logged in to `registry.redhat.io` with your Customer Portal credentials.
-
-* You have installed the real-time kernel in the cluster.
-
-* You have applied a cluster performance profile by using Node Tuning Operator.
+* You have reviewed the prerequisites for running latency tests.
 
 .Procedure
 
@@ -39,7 +35,7 @@ If the results exceed the latency threshold, the test fails.
 +
 [IMPORTANT]
 ====
-For valid results, the test should run for at least 12 hours.
+During testing shorter time periods, as shown, can be used to run the tests. However, for final verification and valid results, the test should run for at least 12 hours (43200 seconds).
 ====
 +
 .Example failure output

modules/cnf-performing-end-to-end-tests-running-hwlatdetect.adoc

@@ -10,14 +10,12 @@ The `hwlatdetect` tool is available in the `rt-kernel` package with a regular su
 
 [NOTE]
 ====
-When executing `podman` commands as a non-root or non-privileged user, mounting paths can fail with `permission denied` errors. To make the `podman` command work, append `:Z` to the volumes creation; for example, `-v $(pwd)/:/kubeconfig:Z`. This allows `podman` to do the proper SELinux relabeling.
+When executing `podman` commands as a non-root or non-privileged user, mounting paths can fail with `permission denied` errors. Depending on your local operating system and SELinux configuration, you might also experience issues running these commands from your home directory. To make the `podman` commands work, run the commands from a folder that is not your home/<username> directory, and append `:Z` to the volumes creation. For example, `-v $(pwd)/:/kubeconfig:Z`. This allows `podman` to do the proper SELinux relabeling.
 ====
 
 .Prerequisites
 
-* You have installed the real-time kernel in the cluster.
-
-* You have logged in to `registry.redhat.io` with your Customer Portal credentials.
+* You have reviewed the prerequisites for running latency tests.
 
 .Procedure
 
@@ -37,7 +35,7 @@ If the results exceed the latency threshold, the test fails.
 +
 [IMPORTANT]
 ====
-For valid results, the test should run for at least 12 hours.
+During testing shorter time periods, as shown, can be used to run the tests. However, for final verification and valid results, the test should run for at least 12 hours (43200 seconds).
 ====
 +
 .Example failure output

modules/cnf-performing-end-to-end-tests-running-oslat.adoc

@@ -10,13 +10,12 @@ The `oslat` test simulates a CPU-intensive DPDK application and measures all the
 
 [NOTE]
 ====
-When executing `podman` commands as a non-root or non-privileged user, mounting paths can fail with `permission denied` errors. To make the `podman` command work, append `:Z` to the volumes creation; for example, `-v $(pwd)/:/kubeconfig:Z`. This allows `podman` to do the proper SELinux relabeling.
+When executing `podman` commands as a non-root or non-privileged user, mounting paths can fail with `permission denied` errors. Depending on your local operating system and SELinux configuration, you might also experience issues running these commands from your home directory. To make the `podman` commands work, run the commands from a folder that is not your home/<username> directory, and append `:Z` to the volumes creation. For example, `-v $(pwd)/:/kubeconfig:Z`. This allows `podman` to do the proper SELinux relabeling.
 ====
 
 .Prerequisites
 
-* You have logged in to `registry.redhat.io` with your Customer Portal credentials.
-* You have applied a cluster performance profile by using the Node Tuning Operator.
+* You have reviewed the prerequisites for running latency tests.
 
 .Procedure
 
@@ -38,7 +37,7 @@ If the results exceed the latency threshold, the test fails.
 +
 [IMPORTANT]
 ====
-For valid results, the test should run for at least 12 hours.
+During testing shorter time periods, as shown, can be used to run the tests. However, for final verification and valid results, the test should run for at least 12 hours (43200 seconds).
 ====
 +
 .Example failure output

modules/cnf-performing-end-to-end-tests-running-the-tests.adoc

@@ -10,34 +10,44 @@ Run the cluster latency tests to validate node tuning for your Cloud-native Netw
 
 [NOTE]
 ====
-When executing `podman` commands as a non-root or non-privileged user, mounting paths can fail with `permission denied` errors. To make the `podman` command work, append `:Z` to the volumes creation; for example, `-v $(pwd)/:/kubeconfig:Z`. This allows `podman` to do the proper SELinux relabeling.
+When executing `podman` commands as a non-root or non-privileged user, mounting paths can fail with `permission denied` errors. Depending on your local operating system and SELinux configuration, you might also experience issues running these commands from your home directory. To make the `podman` commands work, run the commands from a folder that is not your home/<username> directory, and append `:Z` to the volumes creation. For example, `-v $(pwd)/:/kubeconfig:Z`. This allows `podman` to do the proper SELinux relabeling.
 ====
 
+This procedure runs the three individual tests `hwlatdetect`, `cyclictest`, and `oslat`. For details on these individul tests, see their individual sections.
+
 .Procedure
 
 . Open a shell prompt in the directory containing the `kubeconfig` file.
 +
-You provide the test image with a `kubeconfig` file in current directory and its related `$KUBECONFIG` environment variable, mounted through a volume. This allows the running container to use the `kubeconfig` file from inside the container.
-
-. Run the latency tests by entering the following command:
+You provide the test image with a `kubeconfig` file in current directory and its related `$KUBECONFIG` environment variable, mounted through a volume. This allows the running container to use the `kubeconfig` file from inside the container. 
++
+[NOTE]
+====
+In the following command, your local `kubeconfig` is mounted to kubeconfig/kubeconfig in the cnf-tests container, which allows access to the cluster.
+====
++
+. To run the latency tests, run the following command, substituting variable values as appropriate:
 +
 [source,terminal,subs="attributes+"]
 ----
 $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
--e LATENCY_TEST_RUNTIME=<time_in_seconds>\
--e MAXIMUM_LATENCY=<time_in_microseconds> \
+-e LATENCY_TEST_RUNTIME=600\
+-e MAXIMUM_LATENCY=20 \
 registry.redhat.io/openshift4/cnf-tests-rhel8:v{product-version} /usr/bin/test-run.sh \
 --ginkgo.v --ginkgo.timeout="24h"
 ----
-
-. Optional: Append `--ginkgo.dryRun` flag to run the latency tests in dry-run mode. This is useful for checking what commands the tests run.
++
+The LATENCY_TEST_RUNTIME is shown in seconds, in this case 600 seconds (10 minutes). The test runs successfully when the maximum observed latency is lower than MAXIMUM_LATENCY (20 μs).
++
+If the results exceed the latency threshold, the test fails.
++
+. Optional: Append `--ginkgo.dry-run` flag to run the latency tests in dry-run mode. This is useful for checking what commands the tests run.
 
 . Optional: Append `--ginkgo.v` flag to run the tests with increased verbosity.
 
 . Optional: Append `--ginkgo.timeout="24h"` flag to ensure the Ginkgo 2.0 test suite does not timeout before the latency tests complete.
 +
 [IMPORTANT]
 ====
-The default runtime for each test is 300 seconds.
-For valid latency test results, run the tests for at least 12 hours by updating the `LATENCY_TEST_RUNTIME` variable.
+During testing shorter time periods, as shown, can be used to run the tests. However, for final verification and valid results, the test should run for at least 12 hours (43200 seconds).
 ====

scalability_and_performance/low_latency_tuning/cnf-performing-platform-verification-latency-tests.adoc

@@ -15,11 +15,9 @@ The `cnf-tests` container image is available at `registry.redhat.io/openshift4/c
 
 Your cluster must meet the following requirements before you can run the latency tests:
 
-. You have configured a performance profile with the Node Tuning Operator.
+* You have applied all the required CNF configurations. This includes the `PerformanceProfile` cluster and other configuration according to the reference design specifications (RDS) or your specific requirements.
 
-. You have applied all the required CNF configurations in the cluster.
-
-. You have a pre-existing `MachineConfigPool` CR applied in the cluster. The default worker pool is `worker-cnf`.
+* You have logged in to `registry.redhat.io` with your Customer Portal credentials by using the `podman login` command. 
 
 [role="_additional-resources"]
 .Additional resources