From 70f23e92349fad33ce28457606f448fb25b8cc93 Mon Sep 17 00:00:00 2001 From: Kevin Quinn Date: Tue, 23 Jun 2026 10:55:54 +0100 Subject: [PATCH] TELCODOCS-2851: Backport to enterprise-4.20 Backport of https://github.com/openshift/openshift-docs/pull/109197 to enterprise-4.20. 12 files included, 0 files excluded. Co-Authored-By: Claude Opus 4.6 --- .../nw-openstack-hw-offload-testpmd-pod.adoc | 8 +- modules/nw-openstack-sr-iov-testpmd-pod.adoc | 8 +- ...v-network-node-configuration-examples.adoc | 12 +- modules/nw-sriov-device-discovery.adoc | 8 +- .../nw-sriov-exclude-topology-manager.adoc | 1 + modules/nw-sriov-huge-pages.adoc | 1 + .../nw-sriov-networknodepolicy-object.adoc | 113 ++++++++---------- modules/nw-sriov-nic-mlx-secure-boot.adoc | 20 +++- modules/nw-sriov-nic-partitioning.adoc | 17 +-- modules/nw-sriov-topology-manager.adoc | 27 +++-- modules/nw-sriov-troubleshooting.adoc | 17 ++- .../configuring-sriov-device.adoc | 5 +- 12 files changed, 129 insertions(+), 108 deletions(-) diff --git a/modules/nw-openstack-hw-offload-testpmd-pod.adoc b/modules/nw-openstack-hw-offload-testpmd-pod.adoc index f5f904bd39d0..1e4bfb88a964 100644 --- a/modules/nw-openstack-hw-offload-testpmd-pod.adoc +++ b/modules/nw-openstack-hw-offload-testpmd-pod.adoc @@ -6,6 +6,7 @@ [id="nw-openstack-hw-offload-testpmd-pod_{context}"] = A test pod template for clusters that use OVS hardware offloading on OpenStack +[role="_abstract"] The following `testpmd` pod demonstrates Open vSwitch (OVS) hardware offloading on {rh-openstack-first}. .An example `testpmd` pod @@ -19,7 +20,7 @@ metadata: annotations: k8s.v1.cni.cncf.io/networks: hwoffload1 spec: - runtimeClassName: performance-cnf-performanceprofile <1> + runtimeClassName: performance-cnf-performanceprofile containers: - name: testpmd command: ["sleep", "99999"] @@ -47,4 +48,7 @@ spec: emptyDir: medium: HugePages ---- -<1> If your performance profile is not named `cnf-performance profile`, replace that string with the correct performance profile name. + +-- +* If your performance profile is not named `cnf-performance profile`, replace that string with the correct performance profile name. +-- diff --git a/modules/nw-openstack-sr-iov-testpmd-pod.adoc b/modules/nw-openstack-sr-iov-testpmd-pod.adoc index ae98dd0983d9..792672a5b093 100644 --- a/modules/nw-openstack-sr-iov-testpmd-pod.adoc +++ b/modules/nw-openstack-sr-iov-testpmd-pod.adoc @@ -6,6 +6,7 @@ [id="nw-openstack-ovs-sr-iov-testpmd-pod_{context}"] = A test pod template for clusters that use SR-IOV on OpenStack +[role="_abstract"] The following `testpmd` pod demonstrates container creation with huge pages, reserved CPUs, and the SR-IOV port. .An example `testpmd` pod @@ -45,10 +46,13 @@ spec: - mountPath: /dev/hugepages name: hugepage readOnly: False - runtimeClassName: performance-cnf-performanceprofile <1> + runtimeClassName: performance-cnf-performanceprofile volumes: - name: hugepage emptyDir: medium: HugePages ---- -<1> This example assumes that the name of the performance profile is `cnf-performance profile`. \ No newline at end of file + +-- +* This example assumes that the name of the performance profile is `cnf-performance profile`. +-- \ No newline at end of file diff --git a/modules/nw-sr-iov-network-node-configuration-examples.adoc b/modules/nw-sr-iov-network-node-configuration-examples.adoc index 6d83bf3a9a82..5f1487356ef6 100644 --- a/modules/nw-sr-iov-network-node-configuration-examples.adoc +++ b/modules/nw-sr-iov-network-node-configuration-examples.adoc @@ -6,6 +6,7 @@ [id="nw-sr-iov-network-node-configuration-examples_{context}"] = SR-IOV network node configuration examples +[role="_abstract"] The following example describes the configuration for an InfiniBand device: .Example configuration for an InfiniBand device @@ -45,13 +46,16 @@ spec: resourceName: nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" - numVfs: 1 <1> + numVfs: 1 nicSelector: vendor: "" deviceID: "" - netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" <2> + netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" # ... ---- -<1> When configuring the node network policy for a virtual machine, the `numVfs` parameter is always set to `1`. -<2> When the virtual machine is deployed on {rh-openstack}, the `netFilter` parameter must refer to a network ID. Valid values for `netFilter` are available from an `SriovNetworkNodeState` object. + +-- +* When configuring the node network policy for a virtual machine, the `numVfs` parameter is always set to `1`. +* When the virtual machine is deployed on {rh-openstack}, the `netFilter` parameter must refer to a network ID. Valid values for `netFilter` are available from an `SriovNetworkNodeState` object. +-- diff --git a/modules/nw-sriov-device-discovery.adoc b/modules/nw-sriov-device-discovery.adoc index 5e5ad983406d..dea3bdf977c5 100644 --- a/modules/nw-sriov-device-discovery.adoc +++ b/modules/nw-sriov-device-discovery.adoc @@ -7,6 +7,7 @@ [id="discover-sr-iov-devices_{context}"] = Automated discovery of SR-IOV network devices +[role="_abstract"] The SR-IOV Network Operator searches your cluster for SR-IOV capable network devices on worker nodes. The Operator creates and updates a SriovNetworkNodeState custom resource (CR) for each worker node that provides a compatible SR-IOV network device. @@ -79,5 +80,8 @@ status: vendor: "8086" syncStatus: Succeeded ---- -<1> The value of the `name` field is the same as the name of the worker node. -<2> The `interfaces` stanza includes a list of all of the SR-IOV devices discovered by the Operator on the worker node. + +-- +* The value of the `name` field is the same as the name of the worker node. +* The `interfaces` stanza includes a list of all of the SR-IOV devices discovered by the Operator on the worker node. +-- diff --git a/modules/nw-sriov-exclude-topology-manager.adoc b/modules/nw-sriov-exclude-topology-manager.adoc index dfb1942004de..613ec1af9116 100644 --- a/modules/nw-sriov-exclude-topology-manager.adoc +++ b/modules/nw-sriov-exclude-topology-manager.adoc @@ -6,6 +6,7 @@ [id="nw-sriov-exclude-topology-manager_{context}"] = Exclude the SR-IOV network topology for NUMA-aware scheduling +[role="_abstract"] You can exclude advertising the Non-Uniform Memory Access (NUMA) node for the SR-IOV network to the Topology Manager for more flexible SR-IOV network deployments during NUMA-aware pod scheduling. In some scenarios, it is a priority to maximize CPU and memory resources for a pod on a single NUMA node. By not providing a hint to the Topology Manager about the NUMA node for the pod's SR-IOV network resource, the Topology Manager can deploy the SR-IOV network resource and the pod CPU and memory resources to different NUMA nodes. This can add to network latency because of the data transfer between NUMA nodes. However, it is acceptable in scenarios when workloads require optimal CPU and memory performance. diff --git a/modules/nw-sriov-huge-pages.adoc b/modules/nw-sriov-huge-pages.adoc index d401e2633dad..2621a13395e7 100644 --- a/modules/nw-sriov-huge-pages.adoc +++ b/modules/nw-sriov-huge-pages.adoc @@ -6,6 +6,7 @@ [id="nw-sriov-hugepages_{context}"] = Huge pages resource injection for Downward API +[role="_abstract"] When a pod specification includes a resource request or limit for huge pages, the Network Resources Injector automatically adds Downward API fields to the pod specification to provide the huge pages information to the container. The Network Resources Injector adds a volume that is named `podnetinfo` and is mounted at `/etc/podnetinfo` for each container in the pod. The volume uses the Downward API and includes a file for huge pages requests and limits. The file naming convention is as follows: diff --git a/modules/nw-sriov-networknodepolicy-object.adoc b/modules/nw-sriov-networknodepolicy-object.adoc index f955a91f677e..8dad421bf687 100644 --- a/modules/nw-sriov-networknodepolicy-object.adoc +++ b/modules/nw-sriov-networknodepolicy-object.adoc @@ -6,6 +6,7 @@ [id="nw-sriov-networknodepolicy-object_{context}"] = SR-IOV network node configuration object +[role="_abstract"] You specify the SR-IOV network device configuration for a node by creating an SR-IOV network node policy. The API object for the policy is part of the `sriovnetwork.openshift.io` API group. The following YAML describes an SR-IOV network node policy: @@ -15,38 +16,37 @@ The following YAML describes an SR-IOV network node policy: apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: - name: <1> - namespace: openshift-sriov-network-operator <2> + name: + namespace: openshift-sriov-network-operator spec: - resourceName: <3> + resourceName: nodeSelector: - feature.node.kubernetes.io/network-sriov.capable: "true" <4> - priority: <5> - mtu: <6> - needVhostNet: false <7> - numVfs: <8> - externallyManaged: false <9> - nicSelector: <10> - vendor: "" <11> - deviceID: "" <12> - pfNames: ["", ...] <13> - rootDevices: ["", ...] <14> - netFilter: "" <15> - deviceType: <16> - isRdma: false <17> - linkType: <18> - eSwitchMode: "switchdev" <19> - excludeTopology: false <20> + feature.node.kubernetes.io/network-sriov.capable: "true" + priority: + mtu: + needVhostNet: false + numVfs: + externallyManaged: false + nicSelector: + vendor: "" + deviceID: "" + pfNames: ["", ...] + rootDevices: ["", ...] + netFilter: "" + deviceType: + isRdma: false + linkType: + eSwitchMode: "switchdev" + excludeTopology: false ---- -<1> The name for the custom resource object. -<2> The namespace where the SR-IOV Network Operator is installed. +where: -<3> The resource name of the SR-IOV network device plugin. You can create multiple SR-IOV network node policies for a resource name. -+ -When specifying a name, be sure to use the accepted syntax expression `^[a-zA-Z0-9_]+$` in the `resourceName`. - -<4> The node selector specifies the nodes to configure. Only SR-IOV network devices on the selected nodes are configured. The SR-IOV Container Network Interface (CNI) plugin and device plugin are deployed on selected nodes only. +-- +`metadata.name`:: Specifies the name for the custom resource object. +`metadata.namespace`:: Specifies the namespace where the SR-IOV Network Operator is installed. +`spec.resourceName`:: Specifies the resource name of the SR-IOV network device plugin. You can create multiple SR-IOV network node policies for a resource name. When specifying a name, be sure to use the accepted syntax expression `^[a-zA-Z0-9_]+$`. +`spec.nodeSelector`:: Specifies the nodes to configure. Only SR-IOV network devices on the selected nodes are configured. The SR-IOV Container Network Interface (CNI) plugin and device plugin are deployed on selected nodes only. + [IMPORTANT] ==== @@ -54,10 +54,8 @@ The SR-IOV Network Operator applies node network configuration policies to nodes To avoid a node in an unhealthy MCP from blocking the application of node network configuration policies to other nodes, including nodes in other MCPs, you must create a separate node network configuration policy for each MCP. ==== - -<5> Optional: The priority is an integer value between `0` and `99`. A smaller value receives higher priority. For example, a priority of `10` is a higher priority than `99`. The default value is `99`. - -<6> Optional: The maximum transmission unit (MTU) of the physical function and all its virtual functions. The maximum MTU value can vary for different network interface controller (NIC) models. +`spec.priority`:: Optional: Specifies the priority as an integer value between `0` and `99`. A smaller value receives higher priority. For example, a priority of `10` is a higher priority than `99`. The default value is `99`. +`spec.mtu`:: Optional: Specifies the maximum transmission unit (MTU) of the physical function and all its virtual functions. The maximum MTU value can vary for different network interface controller (NIC) models. + [IMPORTANT] ==== @@ -66,12 +64,9 @@ If you want to create virtual function on the default network interface, ensure If you want to modify the MTU of a single virtual function while the function is assigned to a pod, leave the MTU value blank in the SR-IOV network node policy. Otherwise, the SR-IOV Network Operator reverts the MTU of the virtual function to the MTU value defined in the SR-IOV network node policy, which might trigger a node drain. ==== - -<7> Optional: Set `needVhostNet` to `true` to mount the `/dev/vhost-net` device in the pod. Use the mounted `/dev/vhost-net` device with Data Plane Development Kit (DPDK) to forward traffic to the kernel network stack. - -<8> The number of the virtual functions (VF) to create for the SR-IOV physical network device. For an Intel network interface controller (NIC), the number of VFs cannot be larger than the total VFs supported by the device. For a Mellanox NIC, the number of VFs cannot be larger than `127`. - -<9> The `externallyManaged` field indicates whether the SR-IOV Network Operator manages all, or only a subset of virtual functions (VFs). With the value set to `false` the SR-IOV Network Operator manages and configures all VFs on the PF. +`spec.needVhostNet`:: Optional: Set to `true` to mount the `/dev/vhost-net` device in the pod. Use the mounted `/dev/vhost-net` device with Data Plane Development Kit (DPDK) to forward traffic to the kernel network stack. +`spec.numVfs`:: Specifies the number of the virtual functions (VF) to create for the SR-IOV physical network device. For an Intel network interface controller (NIC), the number of VFs cannot be larger than the total VFs supported by the device. For a Mellanox NIC, the number of VFs cannot be larger than `127`. +`spec.externallyManaged`:: Indicates whether the SR-IOV Network Operator manages all, or only a subset of virtual functions (VFs). With the value set to `false` the SR-IOV Network Operator manages and configures all VFs on the PF. + [NOTE] ==== @@ -79,44 +74,34 @@ When `externallyManaged` is set to `true`, you must manually create the Virtual When `externallyManaged` is set to `false`, the SR-IOV Network Operator automatically creates and manages the VFs, including resetting them if necessary. -To use VFs on the host system, you must create them through NMState, and set `externallyManaged` to `true`. In this mode, the SR-IOV Network Operator does not modify the PF or the manually managed VFs, except for those explicitly defined in the `nicSelector` field of your policy. However, the SR-IOV Network Operator continues to manage VFs that are used as pod secondary interfaces. +To use VFs on the host system, you must create them through NMState, and set `externallyManaged` to `true`. In this mode, the SR-IOV Network Operator does not modify the PF or the manually managed VFs, except for those explicitly defined in the `nicSelector` field of your policy. However, the SR-IOV Network Operator continues to manage VFs that are used as pod secondary interfaces. ==== - -<10> The NIC selector identifies the device to which this resource applies. You do not have to specify values for all the parameters. It is recommended to identify the network device with enough precision to avoid selecting a device unintentionally. +`spec.nicSelector`:: Identifies the device to which this resource applies. You do not have to specify values for all the parameters. It is recommended to identify the network device with enough precision to avoid selecting a device unintentionally. + If you specify `rootDevices`, you must also specify a value for `vendor`, `deviceID`, or `pfNames`. If you specify both `pfNames` and `rootDevices` at the same time, ensure that they refer to the same device. If you specify a value for `netFilter`, then you do not need to specify any other parameter because a network ID is unique. - -<11> Optional: The vendor hexadecimal vendor identifier of the SR-IOV network device. The only allowed values are `8086` (Intel) and `15b3` (Mellanox). - -<12> Optional: The device hexadecimal device identifier of the SR-IOV network device. For example, `101b` is the device ID for a Mellanox ConnectX-6 device. - -<13> Optional: An array of one or more physical function (PF) names the resource must apply to. - -<14> Optional: An array of one or more PCI bus addresses the resource must apply to. For example `0000:02:00.1`. - -<15> Optional: The platform-specific network filter. The only supported platform is {rh-openstack-first}. Acceptable values use the following format: `openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`. Replace `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx` with the value from the `/var/config/openstack/latest/network_data.json` metadata file. This filter ensures that VFs are associated with a specific OpenStack network. The operator uses this filter to map the VFs to the appropriate network based on metadata provided by the OpenStack platform. - -<16> Optional: The driver to configure for the VFs created from this resource. The only allowed values are `netdevice` and `vfio-pci`. The default value is `netdevice`. +`spec.nicSelector.vendor`:: Optional: Specifies the vendor hexadecimal identifier of the SR-IOV network device. The only allowed values are `8086` (Intel) and `15b3` (Mellanox). +`spec.nicSelector.deviceID`:: Optional: Specifies the device hexadecimal identifier of the SR-IOV network device. For example, `101b` is the device ID for a Mellanox ConnectX-6 device. +`spec.nicSelector.pfNames`:: Optional: Specifies an array of one or more physical function (PF) names the resource must apply to. +`spec.nicSelector.rootDevices`:: Optional: Specifies an array of one or more PCI bus addresses the resource must apply to. For example `0000:02:00.1`. +`spec.nicSelector.netFilter`:: Optional: Specifies the platform-specific network filter. The only supported platform is {rh-openstack-first}. Acceptable values use the following format: `openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`. Replace `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx` with the value from the `/var/config/openstack/latest/network_data.json` metadata file. This filter ensures that VFs are associated with a specific OpenStack network. The operator uses this filter to map the VFs to the appropriate network based on metadata provided by the OpenStack platform. +`spec.deviceType`:: Optional: Specifies the driver to configure for the VFs created from this resource. The only allowed values are `netdevice` and `vfio-pci`. The default value is `netdevice`. + -For a Mellanox NIC to work in DPDK mode on bare metal nodes, use the `netdevice` driver type and set `isRdma` to `true`. - -<17> Optional: Configures whether to enable remote direct memory access (RDMA) mode. The default value is `false`. +For a Mellanox NIC to work in DPDK mode on bare-metal nodes, use the `netdevice` driver type and set `isRdma` to `true`. +`spec.isRdma`:: Optional: Configures whether to enable remote direct memory access (RDMA) mode. The default value is `false`. + If the `isRdma` parameter is set to `true`, you can continue to use the RDMA-enabled VF as a normal network device. A device can be used in either mode. + -Set `isRdma` to `true` and additionally set `needVhostNet` to `true` to configure a Mellanox NIC for use with Fast Datapath DPDK applications. +Set `isRdma` to `true` and additionally set `needVhostNet` to `true` to configure a Mellanox NIC for use with Fast data path DPDK applications. + [NOTE] ==== -You cannot set the `isRdma` parameter to `true` for intel NICs. +You cannot set the `isRdma` parameter to `true` for Intel NICs. ==== - -<18> Optional: The link type for the VFs. The default value is `eth` for Ethernet. Change this value to 'ib' for InfiniBand. +`spec.linkType`:: Optional: Specifies the link type for the VFs. The default value is `eth` for Ethernet. Change this value to 'ib' for InfiniBand. + When `linkType` is set to `ib`, `isRdma` is automatically set to `true` by the SR-IOV Network Operator webhook. When `linkType` is set to `ib`, `deviceType` should not be set to `vfio-pci`. + -Do not set linkType to `eth` for SriovNetworkNodePolicy, because this can lead to an incorrect number of available devices reported by the device plugin. - -<19> Optional: To enable hardware offloading, you must set the `eSwitchMode` field to `"switchdev"`. For more information about hardware offloading, see "Configuring hardware offloading". - -<20> Optional: To exclude advertising an SR-IOV network resource's NUMA node to the Topology Manager, set the value to `true`. The default value is `false`. +Do not set `linkType` to `eth` for `SriovNetworkNodePolicy`, because this can lead to an incorrect number of available devices reported by the device plugin. +`spec.eSwitchMode`:: Optional: Set to `"switchdev"` to enable hardware offloading. For more information about hardware offloading, see "Configuring hardware offloading". +`spec.excludeTopology`:: Optional: Set to `true` to exclude advertising an SR-IOV network resource's NUMA node to the Topology Manager. The default value is `false`. +-- diff --git a/modules/nw-sriov-nic-mlx-secure-boot.adoc b/modules/nw-sriov-nic-mlx-secure-boot.adoc index 3f2fc7907bfb..711243f557b3 100644 --- a/modules/nw-sriov-nic-mlx-secure-boot.adoc +++ b/modules/nw-sriov-nic-mlx-secure-boot.adoc @@ -6,6 +6,7 @@ [id="nw-sriov-nic-mlx-secure-boot_{context}"] = Configuring the SR-IOV Network Operator on Mellanox cards when Secure Boot is enabled +[role="_abstract"] The SR-IOV Network Operator supports an option to skip the firmware configuration for Mellanox devices. This option allows you to create virtual functions by using the SR-IOV Network Operator when the system has secure boot enabled. You must manually configure and allocate the number of virtual functions in the firmware before switching the system to secure boot. [NOTE] @@ -19,10 +20,13 @@ The number of virtual functions in the firmware is the maximum number of virtual + [source,terminal] ---- -$ mstconfig -d -0001:b1:00.1 set SRIOV_EN=1 NUM_OF_VFS=16 <1> <2> +$ mstconfig -d -0001:b1:00.1 set SRIOV_EN=1 NUM_OF_VFS=16 ---- -<1> The `SRIOV_EN` environment variable enables the SR-IOV Network Operator support on the Mellanox card. -<2> The `NUM_OF_VFS` environment variable specifies the number of virtual functions to enable in the firmware. ++ +-- +* `SRIOV_EN=1` enables the SR-IOV Network Operator support on the Mellanox card. +* `NUM_OF_VFS=16` specifies the number of virtual functions to enable in the firmware. +-- . Configure the SR-IOV Network Operator by disabling the Mellanox plugin. See the following `SriovOperatorConfig` example configuration: + @@ -53,7 +57,8 @@ spec: $ oc -n openshift-sriov-network-operator get sriovnetworknodestate.sriovnetwork.openshift.io worker-0 -oyaml ---- + -.Example output +The following is example output: ++ [source,yaml] ---- - deviceID: 101d @@ -64,11 +69,14 @@ $ oc -n openshift-sriov-network-operator get sriovnetworknodestate.sriovnetwork. mac: 08:c0:eb:96:31:25 mtu: 1500 name: ens3f1np1 - pciAddress: 0000:b1:00.1 <1> + pciAddress: 0000:b1:00.1 totalvfs: 16 vendor: 15b3 ---- -<1> The `totalvfs` value is the same number used in the `mstconfig` command earlier in the procedure. ++ +-- +* The `totalvfs` value is the same number used in the `mstconfig` command earlier in the procedure. +-- . Enable secure boot to prevent unauthorized operating systems and malicious software from loading during the device's boot process. + diff --git a/modules/nw-sriov-nic-partitioning.adoc b/modules/nw-sriov-nic-partitioning.adoc index 21a9750c9deb..9f17e29f2aa6 100644 --- a/modules/nw-sriov-nic-partitioning.adoc +++ b/modules/nw-sriov-nic-partitioning.adoc @@ -6,6 +6,7 @@ [id="nw-sriov-nic-partitioning_{context}"] = Virtual function (VF) partitioning for SR-IOV devices +[role="_abstract"] In some cases, you might want to split virtual functions (VFs) from the same physical function (PF) into many resource pools. For example, you might want some of the VFs to load with the default driver and the remaining VFs load with the `vfio-pci` driver. For example, the following YAML shows the selector for an interface named `netpf0` with VF `2` through `7`: @@ -70,17 +71,19 @@ spec: deviceType: vfio-pci ---- -.Verifying that the interface is successfully partitioned +== Verifying that the interface is successfully partitioned + +Confirm that the interface partitioned to virtual functions (VFs) for the SR-IOV device by running the following command: -* Confirm that the interface partitioned to virtual functions (VFs) for the SR-IOV device by running the following command. -+ [source,terminal] ---- -$ ip link show <1> +$ ip link show ---- -<1> Replace `` with the interface that you specified when partitioning to VFs for the SR-IOV device, for example, `ens3f1`. -+ -.Example output + +`` specifies the interface that you specified when partitioning to VFs for the SR-IOV device, for example, `ens3f1`. + +The following is example output: + [source,terminal] ---- 5: ens3f1: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 diff --git a/modules/nw-sriov-topology-manager.adoc b/modules/nw-sriov-topology-manager.adoc index 607ef62c4f90..960dedd16c3b 100644 --- a/modules/nw-sriov-topology-manager.adoc +++ b/modules/nw-sriov-topology-manager.adoc @@ -6,6 +6,7 @@ [id="nw-sriov-topology-manager_{context}"] = Creating a non-uniform memory access (NUMA) aligned SR-IOV pod +[role="_abstract"] You can create a NUMA aligned SR-IOV pod by restricting SR-IOV and the CPU resources allocated from the same NUMA node with `restricted` or `single-numa-node` Topology Manager policies. .Prerequisites @@ -32,32 +33,38 @@ kind: Pod metadata: name: sample-pod annotations: - k8s.v1.cni.cncf.io/networks: <1> + k8s.v1.cni.cncf.io/networks: spec: containers: - name: sample-container - image: <2> + image: command: ["sleep", "infinity"] resources: limits: - memory: "1Gi" <3> - cpu: "2" <4> + memory: "1Gi" + cpu: "2" requests: memory: "1Gi" cpu: "2" ---- -<1> Replace `` with the name of the SR-IOV network attachment definition CR. -<2> Replace `` with the name of the `sample-pod` image. -<3> To create the SR-IOV pod with guaranteed QoS, set `memory limits` equal to `memory requests`. -<4> To create the SR-IOV pod with guaranteed QoS, set `cpu limits` equals to `cpu requests`. ++ +-- +* `` specifies the name of the SR-IOV network attachment definition CR. +* `` specifies the name of the `sample-pod` image. +* To create the SR-IOV pod with guaranteed QoS, set `memory limits` equal to `memory requests`. +* To create the SR-IOV pod with guaranteed QoS, set `cpu limits` equal to `cpu requests`. +-- . Create the sample SR-IOV pod by running the following command: + [source,terminal] ---- -$ oc create -f <1> +$ oc create -f ---- -<1> Replace `` with the name of the file you created in the previous step. ++ +-- +* `` specifies the name of the file you created in the earlier step. +-- . Confirm that the `sample-pod` is configured with guaranteed QoS. + diff --git a/modules/nw-sriov-troubleshooting.adoc b/modules/nw-sriov-troubleshooting.adoc index 4ebcfbc19b80..c7aae4d2d822 100644 --- a/modules/nw-sriov-troubleshooting.adoc +++ b/modules/nw-sriov-troubleshooting.adoc @@ -6,22 +6,21 @@ [id="nw-sriov-troubleshooting_{context}"] = Troubleshooting SR-IOV configuration +[role="_abstract"] After following the procedure to configure an SR-IOV network device, the following sections address some error conditions. .Procedure * To display the state of nodes, run the following command: - ++ [source,terminal] ---- $ oc get sriovnetworknodestates -n openshift-sriov-network-operator ---- - -where: - -:: Specifies the name of a node with an SR-IOV network device. - ++ +`` specifies the name of a node with an SR-IOV network device. ++ If the output from the command indicates "cannot allocate memory", check the following items: - -* Confirm that global SR-IOV settings are enabled in the BIOS for the node. -* Confirm that VT-d is enabled in the BIOS for the node. ++ +** Confirm that global SR-IOV settings are enabled in the BIOS for the node. +** Confirm that VT-d is enabled in the BIOS for the node. diff --git a/networking/hardware_networks/configuring-sriov-device.adoc b/networking/hardware_networks/configuring-sriov-device.adoc index 0cdd02b70018..2f645e09683f 100644 --- a/networking/hardware_networks/configuring-sriov-device.adoc +++ b/networking/hardware_networks/configuring-sriov-device.adoc @@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] You can configure a Single Root I/O Virtualization (SR-IOV) device in your cluster. Before you perform any tasks in the following documentation, ensure that you xref:../../networking/networking_operators/sr-iov-operator/installing-sriov-operator.adoc#installing-sriov-operator[installed the SR-IOV Network Operator]. @@ -57,7 +58,7 @@ include::modules/nw-sriov-troubleshooting.adoc[leveloffset=+1] * xref:../../scalability_and_performance/using-cpu-manager.adoc#using-cpu-manager[Using CPU Manager] -[id="configuring-sriov-device-next-steps"] -== Next steps +[role="_additional-resources"] +.Additional resources * xref:../../networking/hardware_networks/configuring-sriov-net-attach.adoc#configuring-sriov-net-attach[Configuring an SR-IOV network attachment]