From fdbc87b92b29a2e456f1da9e0fece6963d0f8e79 Mon Sep 17 00:00:00 2001 From: Stephen Smith Date: Tue, 19 May 2020 09:07:16 -0400 Subject: [PATCH] Signed-off-by: Stephen Smith New 4.4 changes from May19 Signed-off-by: Stephen Smith Editorial changes from ahardin. Signed-off-by: Stephen Smith --- _topic_map.yml | 2 +- modules/cnf-configuring-huge-pages.adoc | 86 ++++++++ ...alling-the-performance-addon-operator.adoc | 149 +++++++++++++ ...or-low-latency-via-performanceprofile.adoc | 76 +++++++ modules/cnf-understanding-low-latency.adoc | 2 +- modules/configuring-huge-pages.adoc | 4 +- ...building-and-deploying-a-dpdk-payload.adoc | 204 +++++++++++++++--- ...-addon-operator-for-low-latency-nodes.adoc | 16 +- 8 files changed, 503 insertions(+), 36 deletions(-) create mode 100644 modules/cnf-configuring-huge-pages.adoc create mode 100644 modules/cnf-installing-the-performance-addon-operator.adoc create mode 100644 modules/cnf-tuning-nodes-for-low-latency-via-performanceprofile.adoc diff --git a/_topic_map.yml b/_topic_map.yml index 7aee839b24..35af411f8b 100644 --- a/_topic_map.yml +++ b/_topic_map.yml @@ -1214,7 +1214,7 @@ Topics: File: routing-optimization - Name: What huge pages do and how they are consumed by apps File: what-huge-pages-do-and-how-they-are-consumed-by-apps -- Name: Performance-addon operator for low latency nodes +- Name: Performance Addon Operator for low latency nodes File: cnf-performance-addon-operator-for-low-latency-nodes Distros: openshift-webscale - Name: Using ArgoCD diff --git a/modules/cnf-configuring-huge-pages.adoc b/modules/cnf-configuring-huge-pages.adoc new file mode 100644 index 0000000000..6f86885051 --- /dev/null +++ b/modules/cnf-configuring-huge-pages.adoc @@ -0,0 +1,86 @@ +// Module included in the following assemblies: +//CNF-78 +// * scalability_and_performance/cnf-performance-addon-operator-for-low-latency-nodes.adoc + +[id="cnf-configuring-huge-pages_{context}"] += Configuring huge pages + +Nodes must pre-allocate huge pages used in an {product-title} cluster. Use the +Performance Addon Operator to allocate huge pages on a specific node. + +{product-title} provides a method for creating and allocating huge pages. +Performance Addon Operator provides an easier method for doing this using the +PerformanceProfile. + +For example, in the `hugepages` `pages` section of the PerformanceProfile, +you can specify multiple blocks of `size`, `count`, and, optionally, `node`: + +---- +hugepages: + defaultHugepagesSize: "1Gi" + pages: + - size: "1Gi" + count: 4 + node: 0 <1> +---- + +<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 machineconfigpool status that indicates the update is finished. +==== + +These are the only configuration steps you need to do to allocate huge pages. + +.Verification steps + +* To verify the configuration, see the `/proc/meminfo` file on the node: ++ +---- +# grep -i huge /proc/meminfo +---- ++ +---- +AnonHugePages: ###### ## +ShmemHugePages: 0 kB +HugePages_Total: 2 +HugePages_Free: 2 +HugePages_Rsvd: 0 +HugePages_Surp: 0 +Hugepagesize: #### ## +Hugetlb: #### ## +---- + +* Use `oc debug node` to check that the kernel argument worked by going to one of the worker nodes and listing the +kernel command line arguments (in `/proc/cmdline` on the host): ++ +---- +$ oc debug node/ip-10-0-141-105.ec2.internal +---- ++ +---- +Starting pod/ip-10-0-141-105ec2internal-debug ... +To use host binaries, run `chroot /host` + +sh-4.2# cat /host/proc/cmdline +BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8 +rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16... +coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 selinux=0 + +sh-4.2# exit +---- ++ +You should see the `selinux=0` argument added to the other kernel arguments. + +* Use `oc describe` to report the new size: ++ +---- +$ oc describe node worker-0.ocp4poc.example.com | grep -i huge +---- ++ +---- + hugepages-1g=true + hugepages-###: ### + hugepages-###: ### +---- diff --git a/modules/cnf-installing-the-performance-addon-operator.adoc b/modules/cnf-installing-the-performance-addon-operator.adoc new file mode 100644 index 0000000000..b826bce285 --- /dev/null +++ b/modules/cnf-installing-the-performance-addon-operator.adoc @@ -0,0 +1,149 @@ +// Module included in the following assemblies: +//CNF-78 +// * networking/multiple_networks/configuring-sr-iov.adoc + +[id="installing-the-performance-addon-operator_{context}"] += Installing the Performance Addon Operator + +Performance Addon Operator provides the ability to enable advanced node performance tunings on a set of nodes. +As a cluster administrator, you can install Performance Addon Operator using the {product-title} CLI or the web console. + +[id="install-operator-cli_{context}"] +== Installing the Operator using the CLI + +As a cluster administrator, you can install the Operator using the CLI. + +.Prerequisites + +* A cluster installed on bare-metal hardware. +* The {product-title} Command-line Interface (CLI), commonly known as `oc`. +* Log in as a user with `cluster-admin` privileges. + +.Procedure + +. Create a namespace for the Performance Addon Operator by completing the following actions: + +.. Create the following Namespace Custom Resource (CR) that defines the `openshift-performance-addon-operator` namespace, +and then save the YAML in the `pao-namespace.yaml` file: ++ +---- +apiVersion: v1 +kind: Namespace +metadata: + name: performance-addon-operator + labels: + openshift.io/run-level: "1" +---- + +.. Create the namespace by running the following command: ++ +---- +$ oc create -f pao-namespace.yaml +---- + +. Install the Performance Addon Operator in the namespace you created in the previous step by creating the following objects: + +.. Create the following OperatorGroup CR and save the YAML in the +pao-operatorgroup.yaml` file: ++ +[source,yaml] +---- +apiVersion: operators.coreos.com/v1 +kind: OperatorGroup +metadata: + name: performance-addon-operator + namespace: openshift-performance-addon-operator +spec: + targetNamespaces: + - openshift-performance-addon-operator +---- + +.. Create the OperatorGroup CR by running the following command: ++ +---- +$ oc create -f pao-operatorgroup.yaml +---- + +.. Run the following command to get the `channel` value required for the next +step. ++ +---- +$ oc get packagemanifest performance-addon-operator -n openshift-marketplace -o jsonpath='{.status.defaultChannel}' + +4.4 +---- + +.. Create the following Subscription CR and save the YAML in the `pao-sub.yaml` file: ++ +.Example Subscription +[source,yaml] +---- +apiVersion: operators.coreos.com/v1alpha1 +kind: Subscription +metadata: + name: performance-addon-operator-subscription + namespace: openshift-performance-addon-operator +spec: + channel: <1> + name: performance-addon-operator + source: redhat-operators <2> + sourceNamespace: openshift-marketplace +---- +<1> Specify the value from you obtained in the previous step for the `.status.defaultChannel` parameter. +<2> You must specify the `redhat-operators` value. + +.. Create the Subscription object by running the following command: ++ +---- +$ oc create -f pao-sub.yaml +---- + +.. Change to the `openshift-performance-addon-operator` project: ++ +---- +$ oc project openshift-performance-addon-operator +---- + +[id="install-operator-web-console_{context}"] +== Installing the Performance Addon Operator using the web console + +As a cluster administrator, you can install the Performance Addon Operator using the web console. + +[NOTE] +==== +You have to create the Namespace CR and OperatorGroup CR as mentioned +in the previous section. +==== + +.Procedure + +. Install the Performance Addon Operator using the {product-title} web console: + +.. In the {product-title} web console, click *Operators* -> *OperatorHub*. + +.. Choose *Performance Addon Operator* from the list of available Operators, and then click *Install*. + +.. On the *Create Operator Subscription* page, under *A specific namespace on the cluster* +select *openshift-performance-addon-operator*. Then, click *Subscribe*. + +. Optional: Verify that the performance-addon-operator installed successfully: + +.. Switch to the *Operators* -> *Installed Operators* page. + +.. Ensure that *Performance Addon Operator* is listed in the *openshift-performance-addon-operator* project with a *Status* of *InstallSucceeded*. ++ +[NOTE] +==== +During installation an Operator might display a *Failed* status. +If the installation later succeeds with an *InstallSucceeded* message, you can ignore the *Failed* message. +==== + ++ +If the Operator does not appear as installed, to troubleshoot further: + ++ +* Go to the *Operators* -> *Installed Operators* page and inspect +the *Operator Subscriptions* and *Install Plans* tabs for any failure or errors +under *Status*. +* Go to the *Workloads* -> *Pods* page and check the logs for Pods in the +`performance-addon-operator` project. diff --git a/modules/cnf-tuning-nodes-for-low-latency-via-performanceprofile.adoc b/modules/cnf-tuning-nodes-for-low-latency-via-performanceprofile.adoc new file mode 100644 index 0000000000..51c6b3c20d --- /dev/null +++ b/modules/cnf-tuning-nodes-for-low-latency-via-performanceprofile.adoc @@ -0,0 +1,76 @@ +// Module included in the following assemblies: +// Epic CNF-78 +// scalability_and_performance/cnf-performance-addon-operator-for-low-latency-nodes.adoc + +[IMPORTANT] +==== +The feature described in this document is for *Developer Preview* purposes and is *not supported* by Red Hat at this time. +This feature could cause nodes to reboot and not be available. +==== + +[id="cnf-tuning-nodes-for-low-latency-via-performanceprofile_{context}"] += Tuning nodes for low latency via PerformanceProfile + +The PerformanceProfile lets you control latency tuning aspects of nodes that belong to a certain MachineConfigPool. +After you have specified your settings, the `PerformanceProfile` object is compiled into multiple objects that perform the actual node level tuning: + +* A `MachineConfig` file that manipulates the nodes. +* A `KubeletConfig` file that configures the Topology Manager, the CPU Manager, and the {product-title} nodes. +* The Tuned profile that configures the Node Tuning Operator. + +.Procedure + +. Prepare a cluster. + +. Create a Machine Config Pool. + +. Install the Performance Addon Operator. + +. Create a performance profile that is appropriate for your hardware and topology. +In the PerformanceProfile, you can specify whether to update the kernel to kernel-rt, allocation of hugepages, the CPUs that +will be reserved for operating system housekeeping processes and CPUs that will be used for running the workloads. ++ +This is a typical performance profile: ++ +[source,yaml] +---- +apiversion: performance.openshift.io/v1alpha1 +kind: PerformanceProfile +metadata: + name: +spec: + cpu: + isolated: "1-3" + reserved: "0" + hugepages: + defaultHugepagesSize: "1Gi" + pages: + - size: "1Gi" + count: 4 + node: 0 +realTimeKernel: + enabled: true <1> + numa: + topologyPolicy: "best-effort" + nodeSelector: + node-role.kubernetes.io/worker-cnf: "" +---- + +<1> Valid values are `true` or `false`. Setting the `true` value installs the real-time kernel on the node. + +== Partitioning the CPUs + +You can reserve cores, or threads, for operating system housekeeping tasks from a single NUMA node and put your workloads on another NUMA node. +The reason for this is that the housekeeping processes might be using the CPUs in a way that would impact latency sensitive processes +running on those same CPUs. +Keeping your workloads on a separate NUMA node prevents the processes from interfering with each other. +Additionally, each NUMA node has its own memory bus that is not shared. + +Specify two groups of CPUs in the `spec` section: + +* `isolated` - Has the lowest latency. Processes in this group have no interruptions and so can, for example, +reach much higher DPDK zero packet loss bandwidth. + +* `reserved` - The housekeeping CPUs. Threads in the reserved group tend to be very busy, so latency-sensitive +applications should be run in the isolated group. +See link:https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed[Create a Pod that gets assigned a QoS class of `Guaranteed`]. diff --git a/modules/cnf-understanding-low-latency.adoc b/modules/cnf-understanding-low-latency.adoc index a872347c95..a42e1469ee 100644 --- a/modules/cnf-understanding-low-latency.adoc +++ b/modules/cnf-understanding-low-latency.adoc @@ -41,7 +41,7 @@ set values, installing a kernel, and reconfiguring the machine. But this method requires setting up four different Operators and performing many configurations that, when done manually, is complex and could be prone to mistakes. -{product-title} 4.4 provides a performance-addon Operator to implement automatic +{product-title} 4.4 provides a Performance Addon Operator to implement automatic tuning in order to achieve low latency performance for OpenShift applications. The cluster administrator uses this performance profile configuration that makes it easier to make these changes in a more reliable way. The administrator can diff --git a/modules/configuring-huge-pages.adoc b/modules/configuring-huge-pages.adoc index a87b1fd3e6..bd27683deb 100644 --- a/modules/configuring-huge-pages.adoc +++ b/modules/configuring-huge-pages.adoc @@ -61,6 +61,8 @@ huge pages to verify: ---- $ oc logs \ -n openshift-cluster-node-tuning-operator | grep 'applied$' | tail -n1 - +---- ++ +---- 2019-08-08 07:20:41,286 INFO tuned.daemon.daemon: static tuning from profile 'node-hugepages' applied ---- diff --git a/openshift_images/cnf-building-and-deploying-a-dpdk-payload.adoc b/openshift_images/cnf-building-and-deploying-a-dpdk-payload.adoc index 582f5cf325..e66015d90d 100644 --- a/openshift_images/cnf-building-and-deploying-a-dpdk-payload.adoc +++ b/openshift_images/cnf-building-and-deploying-a-dpdk-payload.adoc @@ -1,5 +1,6 @@ +// Epic CNF-40 [id="cnf-building-and-deploying-a-dpdk-payload"] -= Building and deploying a DPDK payload using the s2i image += Building and deploying a DPDK payload using the S2I image include::modules/common-attributes.adoc[] :context: building-deploying-DPDK-using-s2i-image toc::[] @@ -8,7 +9,7 @@ The Data Plane Development Kit (DPDK) base image is a base image for DPDK applications. It uses the Source-to-Image (S2I) build tool to automate the building of application images. -Source-to-Image (S2I) is a tool for building reproducible, Docker-formatted +Source-to-Image (S2I) is a tool for building reproducible and formatted container images. It produces ready-to-run images by injecting application source into a container image and assembling a new image. The new image incorporates the base image (the builder) and built source. For more @@ -16,23 +17,26 @@ information, see xref:../builds/build-strategies.adoc#build-strategy-s2i_build-strategies[Source-to-Image (S2I) build]. -The DPDK base image that comes preinstalled with DPDK, and a build tool used to -create a target image with DPDK and a user provided application. +The DPDK base image comes preinstalled with DPDK, and with a build tool that can be used to +create a target image containing the DPDK libraries and the application provided by the user. .Prerequisites Before using the S2I tool, ensure that you have the following components installed and configured: -* xref:../registry/configuring-registry-operator.adoc#configuring-registry-operator[Image Registry Operator]. +* OCP Image Registry Operator: +See xref:../registry/configuring-registry-operator.adoc#configuring-registry-operator[Image Registry Operator in OpenShift Container Platform]. -* xref:../networking/hardware_networks/installing-sriov-operator.adoc#installing-sriov-operator[Installing the SR-IOV Network Operator]. +* SR-IOV Operator: +See xref:../networking/hardware_networks/about-sriov.adoc#about-sriov[About SR-IOV hardware on {product-title}]. -An example DPDK-based application base on the dpdk-based image is available in -the link:https://github.com/openshift-kni/cnf-features-deploy/tree/master/tools/s2i-dpdk/test/test-app[cnf-features-deploy] repository. +* Performance AddOn Operator: +See xref:../scalability_and_performance/cnf-performance-addon-operator-for-low-latency-nodes.adoc#performance-addon-operator-for-low-latency-nodes[About CNF Performance Addon Operator]. -This example application is the `test-pmd` application provided by dpdk.org. See the link:https://doc.dpdk.org/guides/testpmd_app_ug/[Testpmd Application User Guide]. +This example application is the `test-pmd` application provided by dpdk.org. +For more information, see link:https://doc.dpdk.org/guides/testpmd_app_ug/[Testpmd Application User Guide]. -.Procedure +.Building procedure To build a target image, create a repository containing an application and the following two scripts: @@ -58,7 +62,8 @@ This is an example of `run.sh`: export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus) echo ${CPU} -echo ${PCIDEVICE_OPENSHIFT_IO_DPDKNIC} +echo ${PCIDEVICE_OPENSHIFT_IO_DPDKNIC} # This is the resource name configured via +the SR-IOV operator. if [ "$RUN_TYPE" == "testpmd" ]; then envsubst < test-template.sh > test.sh @@ -69,17 +74,35 @@ fi while true; do sleep inf; done; ---- +The example `run.sh` will run the commands inside the `test-template.sh`. + +---- +spawn ./customtestpmd -l ${CPU} -w ${PCIDEVICE_OPENSHIFT_IO_DPDKNIC} +--iova-mode=va -- -i --portmask=0x1 --nb-cores=2 --forward-mode=mac --port-topology=loop +--no-mlockall +set timeout 10000 +expect "testpmd>" +send -- "start\r" +sleep 20 +expect "testpmd>" +send -- "stop\r" +expect "testpmd>" +send -- "quit\r" +expect eof +---- + +This file will run the `testpmd` compiled application from the build stage. +This spawns the `testpmd` interactive terminal then start a test workload and close it after 20 seconds. + The DPDK base image and the application repository are both used to build a target application image. S2I copies the application from the repository to the DPDK base image, which then builds a target image using DPDK base image resources and the copied application. You can use the {product-title} BuildConfig to build a target image in a production environment. -A sample manifest file for building the sample DPDK application described above is available in the -link:https://github.com/openshift-kni/cnf-features-deploy/blob/master/feature-configs/demo/dpdk/build-config.yaml[build-config.yaml] file. - The `build-config.yaml` file is the file you use to create your automated build. It creates a new `dpdk` namespace and configures an `ImageStream` for the image and starts a build. +The internal registry must be configured in the cluster. ---- --- @@ -112,13 +135,13 @@ spec: source: <3> contextDir: tools/s2i-dpdk/test/test-app git: - uri: https://github.com/openshift-kni/cnf-features-deploy.git + uri: <4> type: Git - strategy: <4> + strategy: <5> sourceStrategy: from: kind: DockerImage - name: quay.io/schseba/dpdk-s2i-base:ds + name: registry.access.redhat.com/openshift4/dpdk-base-rhel8:v4.4 type: Source successfulBuildsHistoryLimit: 5 triggers: @@ -131,7 +154,9 @@ spec: <3> The `source` type contains the git repository and a context directory within the repository. -<4> The `strategy` type contains a DPDK base image. +<4> The repository uri that contains the application and both the `build.sh` and the `run.sh` files. + +<5> The `strategy` type contains a DPDK base image. It is the `source` type and `strategy` type that build the image. @@ -139,17 +164,140 @@ A complete guide to using BuildConfigs is available in xref:../builds/understanding-buildconfigs.adoc#understanding-buildconfigs[Understanding build configurations]. -After the base DPDK image build is ready, create a new directory with a -`kustomization.yaml` file and a `build-config.yaml` patch. +After the base DPDK image build is ready, you should configure the environment to be able to run the DPDK workload on it. -This is an example of `kustomization.yaml`: +.Deployment procedure +. Create a performance profile to allocate Hugepages and isolated CPUs. For more +information, see +xref:../scalability_and_performance/cnf-performance-addon-operator-for-low-latency-nodes.adoc#cnf-understanding-low-latency_{context}[Tuning +nodes for low latency via PerformanceProfile]. + +. Create the SR-IOV network policy and the SR-IOV network attachment based on your network card type. For more information, +see xref:../networking/hardware_networks/using-dpdk-and-rdma.adoc#using-dpdk-and-rdma[Using Virtual Functions (VFs) with DPDK and RDMA modes]. + +. Using a deployment config resource instead of a regular deployment allows automatic redeploy of the workload whenever a new image is built. +You must create a special `SecurityContextConstraints` resource that will allow the `deployer` service account to create the +dpdk workload deployment and the deployment config resource pointing to the `ImageStream`. ++ +`SecurityContextConstraints` example: ++ ---- -apiVersion: kustomize.config.k8s.io/v1beta1 -kind: Kustomization - -bases: - - ../demo/dpdk -patchesStrategicMerge: - - build-config.yaml +apiVersion: security.openshift.io/v1 +kind: SecurityContextConstraints +metadata: + name: dpdk +allowHostDirVolumePlugin: true +allowHostIPC: false +allowHostNetwork: false +allowHostPID: false +allowHostPorts: false +allowPrivilegeEscalation: false +allowPrivilegedContainer: false +allowedCapabilities: + - "*" +allowedUnsafeSysctls: + - "*" +defaultAddCapabilities: null +fsGroup: + type: RunAsAny +readOnlyRootFilesystem: false +runAsUser: + type: RunAsAny +seLinuxContext: + type: RunAsAny +seccompProfiles: + - "*" +users: <1> + - system:serviceaccount:dpdk:deployer +volumes: + - "*" ---- ++ +<1> This is a list of all the service accounts that will be part of the SCC. +You should add here all the namespaces that will deploy the dpdk workload in the following format `system:serviceaccount::deployer`. + +. Apply the deployment config resource. ++ +`DeploymentConfig` resource example: ++ +---- +apiVersion: apps.openshift.io/v1 +kind: DeploymentConfig +metadata: + labels: + app: s2i-dpdk-app + app.kubernetes.io/component: s2i-dpdk-app + app.kubernetes.io/instance: s2i-dpdk-app + name: s2i-dpdk-app + namespace: dpdk +spec: + replicas: 1 + revisionHistoryLimit: 10 + selector: + deploymentconfig: s2i-dpdk-app + strategy: + rollingParams: + intervalSeconds: 1 + maxSurge: 25% + maxUnavailable: 25% + timeoutSeconds: 600 + updatePeriodSeconds: 1 + type: Rolling + template: + metadata: + labels: + deploymentconfig: s2i-dpdk-app + annotations: + k8s.v1.cni.cncf.io/networks: dpdk/dpdk-network <1> + spec: + serviceAccount: deployer + serviceAccountName: deployer + securityContext: + runAsUser: 0 + containers: + - image: “//:” <2> + securityContext: + runAsUser: 0 + capabilities: + add: ["IPC_LOCK","SYS_RESOURCE"] + imagePullPolicy: Always + name: s2i-dpdk-app + terminationMessagePath: /dev/termination-log + terminationMessagePolicy: File + resources: <3> + limits: + cpu: "4" + hugepages-1Gi: 4Gi + memory: 1000Mi + requests: + cpu: "4" + hugepages-1Gi: 4Gi + memory: 1000Mi + volumeMounts: + - mountPath: /mnt/huge + name: hugepage + dnsPolicy: ClusterFirst + volumes: + - name: hugepage + emptyDir: + medium: HugePages + restartPolicy: Always + test: false + triggers: + - type: ConfigChange + - imageChangeParams: + automatic: true + containerNames: + - s2i-dpdk-app + from: <4> + kind: ImageStreamTag + name: : + namespace: + type: ImageChange +---- ++ +<1> The network attachment definition name. +<2> The image stream URL. +<3> The requested resource. The limit and request should be the same so the quality of service (QOS) will be guaranteed and the CPUs will be pinned. +<4> The image stream created to start a redeployment when a newly built image is pushed to the registry. diff --git a/scalability_and_performance/cnf-performance-addon-operator-for-low-latency-nodes.adoc b/scalability_and_performance/cnf-performance-addon-operator-for-low-latency-nodes.adoc index 305291962d..60a7ee48b5 100644 --- a/scalability_and_performance/cnf-performance-addon-operator-for-low-latency-nodes.adoc +++ b/scalability_and_performance/cnf-performance-addon-operator-for-low-latency-nodes.adoc @@ -1,5 +1,5 @@ [id="performance-addon-operator-for-low-latency-nodes"] -= Performance-addon operator for low latency nodes += Performance Addon Operator for low latency nodes include::modules/common-attributes.adoc[] :context: cnf-master @@ -7,16 +7,22 @@ toc::[] include::modules/cnf-understanding-low-latency.adoc[leveloffset=+1] -include::modules/nw-sriov-installing-operator.adoc[leveloffset=+1] +include::modules/cnf-installing-the-performance-addon-operator.adoc[leveloffset=+1] -include::modules/configuring-huge-pages.adoc[leveloffset=+1] +include::modules/cnf-configuring-huge-pages.adoc[leveloffset=+1] -include::modules/cnf-creating-the-performance-profile-object.adoc[leveloffset=+1] +include::modules/cnf-tuning-nodes-for-low-latency-via-performanceprofile.adoc[leveloffset=+1] .Additional resources -* For more information about Machine Config and KubeletConfig, +* For more information about MachineConfig and KubeletConfig, see xref:../nodes/nodes/nodes-nodes-managing.adoc#nodes-nodes-managing[Managing nodes]. * For more information about the Node Tuning Operator, see xref:../scalability_and_performance/using-node-tuning-operator.adoc#using-node-tuning-operator[Using the Node Tuning Operator]. + +* For more information about the PerformanceProfile, +see xref:../scalability_and_performance/what-huge-pages-do-and-how-they-are-consumed-by-apps.adoc#configuring-huge-pages_huge-pages[Configuring huge pages]. + +* For more information about consuming huge pages from your containers, +see xref:../scalability_and_performance/what-huge-pages-do-and-how-they-are-consumed-by-apps.adoc#how-huge-pages-are-consumed-by-apps_huge-pages[How huge pages are consumed by apps].