anchor.diff:  ----
   $ docker run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig -e PERFORMANCE_PROFILE_MANIFEST_OVERRIDE=/kubeconfig/manifest.yaml registry.redhat.io/openshift4/cnf-tests-rhel8:v4.8 /usr/bin/test-run.sh
   ----
  -
  -[id="cnf-performing-end-to-end-tests-cluster-impacts_{context}"]
  -== Impacts on the cluster
  -
  -Depending on the feature, running the test suite could cause different impacts on the cluster. In general, only the SCTP tests do not change the cluster configuration. All of the other features have various impacts on the configuration.
  -
  -[id="cnf-performing-end-to-end-tests-sctp_{context}"]
  -=== SCTP
  -
  -SCTP tests just run different pods on different nodes to check connectivity. The impacts on the cluster are related to running simple pods on two nodes.
  -
  -[id="cnf-performing-end-to-end-tests-xtu32_{context}"]
  -=== XT_U32
  -
  -XT_U32 tests run pods on different nodes to check iptables rule that utilize xt_u32. The impacts on the cluster are related to running simple pods on two nodes.
  -
  -[id="cnf-performing-end-to-end-tests-sr-iov_{context}"]
  -=== SR-IOV
  -
  -SR-IOV tests require changes in the SR-IOV network configuration, where the tests create and destroy different types of configuration.
  -
  -This might have an impact if existing SR-IOV network configurations are already installed on the cluster, because there may be conflicts depending on the priority of such configurations.
  -
  -At the same time, the result of the tests might be affected by existing configurations.
  -
  -[id="cnf-performing-end-to-end-tests-ptp_{context}"]
  -=== PTP
  -
  -PTP tests apply a PTP configuration to a set of nodes of the cluster. As with SR-IOV, this might conflict with any existing PTP configuration already in place, with unpredictable results.
  -
  -[id="cnf-performing-end-to-end-tests-performance_{context}"]
  -=== Performance
  -
  -Performance tests apply a performance profile to the cluster. The effect of this is changes in the node configuration, reserving CPUs, allocating memory huge pages, and setting the kernel packages to be realtime. If an existing profile named `performance` is already available on the cluster, the tests do not deploy it.
  -
  -[id="cnf-performing-end-to-end-tests-dpdk_{context}"]
  -=== DPDK
  -
  -DPDK relies on both performance and SR-IOV features, so the test suite configures both a performance profile and SR-IOV networks, so the impacts are the same as those described in SR-IOV testing and performance testing.
  -
  -[id="cnf-performing-end-to-end-tests-container-mount-namespace_{context}"]
  -=== Container-mount-namespace
  -
  -The validation test for `container-mount-namespace` mode only checks that the appropriate `MachineConfig` objects are present and active, and has no additional impact on the node.
  -
  -[id="cnf-performing-end-to-end-tests-cleaning-up_{context}"]
  -=== Cleaning up
  -
  -After running the test suite, all the dangling resources are cleaned up.
positive.code: ====
  Currently, not all tests run selectively on the nodes belonging to the pool.
  ====
  
  [id="cnf-performing-end-to-end-tests-running-the-tests_{context}"]
  == Running the latency tests
  
negative.code: <1> The list of CPUs running the `oslat` command. Seven CPUs are provided through the `LATENCY_TEST_CPUS` variable. Only six CPUs are displayed in total because one is used to run the `oslat` tool.
  <2> The user is notified about the measured latency and the configured latency.
  <3> The maximum latency values in microseconds that are measured on each CPU.
  
  [id="cnf-performing-end-to-end-tests-troubleshooting_{context}"]
  == Troubleshooting
  