18.2. 配置 SR-IOV 网络设备

您可以在集群中配置单一根 I/O 虚拟化（SR-IOV）设备。

在执行以下文档中的任何任务前，请确保安装了 SR-IOV Network Operator。

18.2.1. SR-IOV 网络节点配置对象

您可以通过创建 SR-IOV 网络节点策略来为节点指定 SR-IOV 网络设备配置。策略的 API 对象是 sriovnetwork.openshift.io API 组的一部分。

以下 YAML 描述了 SR-IOV 网络节点策略：

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name> 1
  namespace: openshift-sriov-network-operator 2
spec:
  resourceName: <sriov_resource_name> 3
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true" 4
  priority: <priority> 5
  mtu: <mtu> 6
  needVhostNet: false 7
  numVfs: <num> 8
  externallyManaged: false 9
  nicSelector: 10
    vendor: "<vendor_code>" 11
    deviceID: "<device_id>" 12
    pfNames: ["<pf_name>", ...] 13
    rootDevices: ["<pci_bus_id>", ...] 14
    netFilter: "<filter_string>" 15
  deviceType: <device_type> 16
  isRdma: false 17
  linkType: <link_type> 18
  eSwitchMode: "switchdev" 19
  excludeTopology: false 20

1

自定义资源对象的名称。

2

安装 SR-IOV Network Operator 的命名空间。

3

SR-IOV 网络设备插件的资源名称。您可以为资源名称创建多个 SR-IOV 网络节点策略。

在指定名称时，请确保在 resourceName 中使用接受的语法表达式 ^[a-zA-Z0-9_]+$。

4

节点选择器指定要配置的节点。只有所选节点上的 SR-IOV 网络设备才会被配置。SR-IOV Container Network Interface（CNI）插件和设备插件仅在所选节点上部署。

重要

SR-IOV Network Operator 按顺序将节点网络配置策略应用到节点。在应用节点网络配置策略前，SR-IOV Network Operator 会检查节点的机器配置池(MCP)是否处于不健康状态，如 Degraded 或 Updating。如果节点处于不健康的 MCP，将节点网络配置策略应用到集群中的所有目标节点的过程会被暂停，直到 MCP 返回健康状态。

为了避免处于不健康的 MCP 的节点阻止将节点网络配置策略应用到其他节点，包括处于其他 MCP 的节点，您必须为每个 MCP 创建单独的节点网络配置策略。

5

可选： priority 是一个 0 到 99 之间的整数。较小的值具有更高的优先级。例如，优先级 10 是高于优先级 99。默认值为 99。

6

可选：物理功能及其所有虚拟功能的最大传输单元(MTU)。最大 MTU 值可能因不同的网络接口控制器（NIC）型号而有所不同。

重要

如果要在默认网络接口上创建虚拟功能，请确保将 MTU 设置为与集群 MTU 匹配的值。

如果要修改单个虚拟功能的 MTU，同时将功能分配给 pod，请将 MTU 值留在 SR-IOV 网络节点策略中。否则，SR-IOV Network Operator 会将虚拟功能的 MTU 恢复到 SR-IOV 网络节点策略中定义的 MTU 值，这可能会触发节点排空。

7

可选：将 needVhostNet 设置为 true，以在 pod 中挂载 /dev/vhost-net 设备。使用挂载的 /dev/vhost-net 设备及 Data Plane Development Kit (DPDK) 将流量转发到内核网络堆栈。

8

为 SR-IOV 物理网络设备创建的虚拟功能(（VF）的数量。对于 Intel 网络接口控制器（NIC），VF 的数量不能超过该设备支持的 VF 总数。对于 Mellanox NIC，VF 的数量不能超过 127。

9

externallyManaged 字段指示 SR-IOV Network Operator 是否管理所有，或只是虚拟功能(VF)的子集。将值设为 false 时，SR-IOV Network Operator 管理并配置 PF 上的所有 VF。

注意

当 externalManaged 设置为 true 时，您必须在应用 SriovNetworkNodePolicy 资源前在物理功能(PF)上手动创建虚拟功能(VF)。如果没有预先创建 VF，SR-IOV Network Operator 的 Webhook 将阻止策略请求。

当 externallyManaged 设为 false 时，SR-IOV Network Operator 会自动创建和管理 VF，包括重置 VF （如果需要）。

要在主机系统上使用 VF，您必须通过 NMState 创建它们，并将 externallyManaged 设置为 true。在这个模式中，SR-IOV Network Operator 不会修改 PF 或手动管理的 VF，策略 nicSelector 字段中明确定义的 VF 除外。但是，SR-IOV Network Operator 继续管理用作 pod 二级接口的 VF。

10

NIC 选择器标识此资源应用到的设备。您不必为所有参数指定值。建议您足够精确地识别网络设备以避免意外选择设备。

如果指定了rootDevices，则必须同时为 vendor、 deviceID 或 pfNames 指定一个值。如果同时指定了 pfNames 和 rootDevices，请确保它们引用同一设备。如果您为 netFilter 指定了一个值，那么您不需要指定任何其他参数，因为网络 ID 是唯一的。

11

可选： SR-IOV 网络设备厂商的十六进制厂商代码。允许的值只能是 8086 (Intel)和 15b3 (Mellanox)。

12

可选： SR-IOV 网络设备的十六进制设备标识符。例如，101b 是 Mellanox ConnectX-6 设备的设备 ID。

13

可选：资源需要应用到的一个或多个物理功能(PF)名称的数组。

14

可选：资源需要应用到的一个或多个 PCI 总线地址的数组。例如 0000:02:00.1。

15

可选：特定平台的网络过滤器。唯一支持的平台是 Red Hat OpenStack Platform（RHOSP）。可接受的值具有以下格式： openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx。将 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxx 替换为来自 /var/config/openstack/latest/network_data.json 元数据文件的值。此过滤器确保 VF 与特定的 OpenStack 网络关联。Operator 使用此过滤器根据 OpenStack 平台提供的元数据将 VF 映射到适当的网络。

16

可选：为从此资源创建的 VF 配置的驱动程序。允许的值只能是 netdevice 和 vfio-pci。默认值为 netdevice。

对于裸机节点上的 DPDK 模式的 Mellanox NIC，请使用 netdevice 驱动程序类型，并将 isRdma 设置为 true。

17

可选：配置是否启用远程直接访问 (RDMA) 模式。默认值为 false。

如果 isRdma 参数设为 true，您可以继续使用启用了 RDMA 的 VF 作为普通网络设备。设备可在其中的一个模式中使用。

将 isRdma 设置为 true，并将 needVhostNet 设置为 true 以配置 Mellanox NIC 以用于 Fast Datapath DPDK 应用程序。

注意

对于 intel NIC，您无法将 isRdma 参数设置为 true。

18

可选：VF 的链接类型。默认值为 eth （以太网）。在 InfiniBand 中将这个值改为 'ib'。

当将 linkType 设置为 ib 时，SR-IOV Network Operator Webhook 会自动将 isRdma 设置为 true。当将 linkType 设定为 ib 时，deviceType 不应该被设置为 vfio-pci。

不要为 SriovNetworkNodePolicy 将 linkType 设置为 eth，因为这可能会导致设备插件报告的可用设备数量不正确。

19

可选：要启用硬件卸载，您必须将 eSwitchMode 字段设置为 "switchdev"。有关硬件卸载的更多信息，请参阅"配置硬件卸载"。

20

可选：要排除将一个 SR-IOV 网络资源的 NUMA 节点广告到拓扑管理器，将值设为 true。默认值为 false。

18.2.1.1. SR-IOV 网络节点配置示例

以下示例描述了 InfiniBand 设备的配置：

InfiniBand 设备的配置示例

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name>
  namespace: openshift-sriov-network-operator
spec:
  resourceName: <sriov_resource_name>
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: <num>
  nicSelector:
    vendor: "<vendor_code>"
    deviceID: "<device_id>"
    rootDevices:
      - "<pci_bus_id>"
  linkType: <link_type>
  isRdma: true
# ...

以下示例描述了 RHOSP 虚拟机中的 SR-IOV 网络设备配置：

虚拟机中的 SR-IOV 设备配置示例

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name>
  namespace: openshift-sriov-network-operator
spec:
  resourceName: <sriov_resource_name>
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1 1
  nicSelector:
    vendor: "<vendor_code>"
    deviceID: "<device_id>"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" 2
# ...

1: 为虚拟机配置节点网络策略时，numVfs 参数始终设置为 1。
2: 当虚拟机部署在 RHOSP 上时，netFilter 参数必须引用一个网络 ID。netFilter 的有效值来自 SriovNetworkNodeState 对象。

18.2.1.2. 自动发现 SR-IOV 网络设备

SR-IOV Network Operator 将搜索集群以获取 worker 节点上的 SR-IOV 功能网络设备。Operator 会为每个提供兼容 SR-IOV 网络设备的 worker 节点创建并更新一个 SriovNetworkNodeState 自定义资源 (CR) 。

为 CR 分配了与 worker 节点相同的名称。status.interfaces 列表提供有关节点上网络设备的信息。

重要

不要修改 SriovNetworkNodeState 对象。Operator 会自动创建和管理这些资源。

18.2.1.2.1. SriovNetworkNodeState 对象示例

以下 YAML 是由 SR-IOV Network Operator 创建的 SriovNetworkNodeState 对象的示例：

一个 SriovNetworkNodeState 对象

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25 1
  namespace: openshift-sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: "39824"
status:
  interfaces: 2
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f0
    pciAddress: "0000:18:00.0"
    totalvfs: 8
    vendor: 15b3
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f1
    pciAddress: "0000:18:00.1"
    totalvfs: 8
    vendor: 15b3
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f0
    pciAddress: 0000:81:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f1
    pciAddress: 0000:81:00.1
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens803f0
    pciAddress: 0000:86:00.0
    totalvfs: 64
    vendor: "8086"
  syncStatus: Succeeded

1: name 字段的值与 worker 节点的名称相同。
2: interfaces 小节包括 Operator 在 worker 节点上发现的所有 SR-IOV 设备列表。

18.2.1.3. SR-IOV 设备的虚拟功能 (VF) 分区

在某些情况下，您可能想要将同一个物理功能 (PF) 的虚拟功能 (VF) 分成多个资源池。例如：您可能想要某些 VF 使用默认驱动程序载入，而其他的 VF 负载使用 vfio-pci 驱动程序。在这样的部署中，您可以使用SriovNetworkNodePolicy 自定义资源 (CR) 中的 pfNames 选项器（selector）来为池指定 VF 的范围，其格式为： <pfname>#<first_vf>-<last_vf>。

例如，以下 YAML 显示名为 netpf0 的、带有 VF 2 到 7 的接口的选择器：

pfNames: ["netpf0#2-7"]

netpf0 是 PF 接口名称。
2 是包含在范围内的第一个 VF 索引（基于 0)。
7 是包含在范围内的最后一个 VF 索引（基于 0)。

如果满足以下要求，您可以使用不同的策略 CR 从同一 PF 中选择 VF:

选择相同 PF 的不同策略的 numVfs 值必须相同。
VF 索引范围是从 0 到 <numVfs>-1 之间。例如，如果您有一个策略，它的 numVfs 被设置为 8，则 <first_vf> 的值不能小于 0，<last_vf> 的值不能大于 7。
不同策略中的 VF 范围不得互相重叠。
<first_vf> 不能大于 <last_vf>。

以下示例演示了 SR-IOV 设备的 NIC 分区。

策略 policy-net-1 定义了一个资源池 net-1，其中包含带有默认 VF 驱动的 PF netpf0 的 VF 0 。策略 policy-net-1-dpdk 定义了一个资源池 net-1-dpdk，其中包含带有 vfio VF 驱动程序的 PF netpf0 的 VF 8 到 15。

策略 policy-net-1:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#0-0"]
  deviceType: netdevice

策略 policy-net-1-dpdk:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1-dpdk
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1dpdk
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#8-15"]
  deviceType: vfio-pci

验证接口是否已成功分区

运行以下命令，确认 SR-IOV 设备的接口分区到虚拟功能(VF)。

$ ip link show <interface> 1

1: 将 <interface> 替换为您在分区为 SR-IOV 设备的 VF 时指定的接口，如 ens3f1。

输出示例

5: ens3f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:d1:bc:01 brd ff:ff:ff:ff:ff:ff

vf 0     link/ether 5a:e7:88:25:ea:a0 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 1     link/ether 3e:1d:36:d7:3d:49 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 2     link/ether ce:09:56:97:df:f9 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 3     link/ether 5e:91:cf:88:d1:38 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 4     link/ether e6:06:a1:96:2f:de brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

18.2.1.4. 在 OpenStack 上使用 SR-IOV 的集群测试 pod 模板

以下 testpmd pod 演示了使用巨页、保留 CPU 和 SR-IOV 端口创建容器。

testpmd pod 示例

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/sriov1: 1
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/sriov1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 1
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

1: 本例假定性能配置集的名称为 cnf-performance profile。

18.2.1.5. 在 OpenStack 上使用 OVS 硬件卸载的集群测试 pod 模板

以下 testpmd pod 在 Red Hat OpenStack Platform (RHOSP) 上演示了 Open vSwitch (OVS) 硬件卸载。

testpmd pod 示例

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/networks: hwoffload1
spec:
  runtimeClassName: performance-cnf-performanceprofile 1
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
    volumeMounts:
      - mountPath: /mnt/huge
        name: hugepage
        readOnly: False
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

1: 如果您的性能配置集没有命名为 cnf-performance profile，请将该字符串替换为正确的性能配置集名称。

18.2.1.6. Downward API 的巨页资源注入

当 pod 规格包含巨页的资源请求或限制时，Network Resources Injector 会自动在 pod 规格中添加 Downward API 字段，以便为容器提供巨页信息。

Network Resources Injector 添加一个名为 podnetinfo 的卷，并挂载到 pod 中的每个容器的 /etc/podnetinfo。卷使用 Downward API，并包含一个用于大页面请求和限制的文件。文件命名规则如下：

/etc/podnetinfo/hugepages_1G_request_<container-name>
/etc/podnetinfo/hugepages_1G_limit_<container-name>
/etc/podnetinfo/hugepages_2M_request_<container-name>
/etc/podnetinfo/hugepages_2M_limit_<container-name>

上一个列表中指定的路径与 app-netutil 库兼容。默认情况下，该库配置为搜索 /etc/podnetinfo 目录中的资源信息。如果您选择自己手动指定 Downward API 路径项目，app-netutil 库除上一个列表中的路径外还会搜索以下路径。

/etc/podnetinfo/hugepages_request
/etc/podnetinfo/hugepages_limit
/etc/podnetinfo/hugepages_1G_request
/etc/podnetinfo/hugepages_1G_limit
/etc/podnetinfo/hugepages_2M_request
/etc/podnetinfo/hugepages_2M_limit

与 Network Resources Injector 可以创建的路径一样，以上列表中的路径可以选择以一个 _<container-name> 后缀结尾。

18.2.2. 配置 SR-IOV 网络设备

SR-IOV Network Operator 把 SriovNetworkNodePolicy.sriovnetwork.openshift.io CRD 添加到 OpenShift Container Platform。您可以通过创建一个 SriovNetworkNodePolicy 自定义资源 (CR) 来配置 SR-IOV 网络设备。

注意

在应用由 SriovNetworkNodePolicy 对象中指定的配置时，SR-IOV Operator 可能会排空节点，并在某些情况下会重启节点。仅在以下情况下重启：

使用 Mellanox NIC (mlx5 驱动程序) 时，每次当在一个物理功能（PF）中的虚拟功能 (VF) 数量增加时，节点都会重启。
使用 Intel NIC 时，只有在内核参数不包含 intel_iommu=on 和 iommu=pt 时，才会重启。

它可能需要几分钟时间来应用配置更改。

先决条件

已安装 OpenShift CLI（oc）。
您可以使用具有 cluster-admin 角色的用户访问集群。
已安装 SR-IOV Network Operator。
集群中有足够的可用节点，用于处理从排空节点中驱除的工作负载。
您还没有为 SR-IOV 网络设备配置选择任何 control plane 节点。

流程

创建一个 SriovNetworkNodePolicy 对象，然后在 <name>-sriov-node-network.yaml 文件中保存 YAML。使用配置的实际名称替换 <name>。
可选：将 SR-IOV 功能的集群节点标记为 SriovNetworkNodePolicy.Spec.NodeSelector （如果它们还没有标记）。有关标记节点的更多信息，请参阅"了解如何更新节点上的标签"。
创建 SriovNetworkNodePolicy 对象：
```
$ oc create -f <name>-sriov-node-network.yaml
```
其中 <name> 指定这个配置的名称。
在应用配置更新后，sriov-network-operator 命名空间中的所有 Pod 都会变为 Running 状态。
要验证是否已配置了 SR-IOV 网络设备，请输入以下命令。将 <node_name> 替换为带有您刚才配置的 SR-IOV 网络设备的节点名称。
```
$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```

其他资源

了解如何更新节点上的标签。

18.2.3. 创建与 SR-IOV pod 兼容的非统一内存访问 (NUMA)

您可以通过限制 SR-IOV 和从相同 NUMA 节点分配的 CPU 资源，使用 restricted 或 single-numa-node Topology Manager 来创建与 SR-IOV pod 兼容的 NUMA。

先决条件

已安装 OpenShift CLI(oc)。
您已将 CPU Manager 策略配置为 static。有关 CPU Manager 的详情请参考 "Additional resources" 部分。
您已将 Topology Manager 策略配置为 single-numa-node。
注意
当 single-numa-node 无法满足请求时，您可以将拓扑管理器策略配置为 restricted。有关更灵活的 SR-IOV 网络资源调度，请参阅附加资源部分中的 NUMA 感知调度过程中排除 SR-IOV 网络拓扑。

流程

创建以下 SR-IOV pod 规格，然后在 <name>-sriov-pod.yaml 文件中保存 YAML。将 <name> 替换为这个 pod 的名称。
以下示例显示了 SR-IOV pod 规格：
```
apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: <name> 1
spec:
  containers:
  - name: sample-container
    image: <image> 2
    command: ["sleep", "infinity"]
    resources:
      limits:
        memory: "1Gi" 3
        cpu: "2" 4
      requests:
        memory: "1Gi"
        cpu: "2"
```
1
将 <name> 替换为 SR-IOV 网络附加定义 CR 的名称。
2
将 <image> 替换为 sample-pod 镜像的名称。
3
要创建带有保证 QoS 的 SR-IOV pod，将 memory limits 设置为与 memory requests 相同的值。
4
要创建带有保证 QoS 的 SR-IOV pod，将 cpu limits 设置为与 cpu requests 相同。
运行以下命令来创建 SR-IOV pod 示例：
```
$ oc create -f <filename> 1
```
1
将 <filename> 替换为您在上一步中创建的文件的名称。
确认 sample-pod 配置为带有保证 QoS。
```
$ oc describe pod sample-pod
```

确认 sample-pod 被分配了独有的 CPU。

$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus

确认为 sample-pod 分配的 SR-IOV 设备和 CPU 位于相同的 NUMA 节点上。
```
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
```

18.2.4. 为 NUMA 感知调度排除 SR-IOV 网络拓扑

在 NUMA 感知 pod 调度过程中，可以排除将 SR-IOV 网络的 Non-Uniform Memory Access (NUMA) 节点广告到拓扑管理器，以便实现更灵活的 SR-IOV 网络部署。

在某些情况下，为在单个 NUMA 节点上的一个 pod 最大化 CPU 和内存资源是一个优先操作。如果没有为 Topology Manager 提供有关 pod 的 SR-IOV 网络资源的 NUMA 节点的提示，拓扑管理器可能会将 SR-IOV 网络资源和 pod CPU 和内存资源部署到不同的 NUMA 节点。这可能会添加到网络延迟，因为需要在不同 NUMA 节点之间进行数据传输。但是，当工作负载需要最佳 CPU 和内存性能时，这是可以接受的。

例如，有一个计算节点 compute-1，它有两个 NUMA 节点：numa0 和 numa1。启用了 SR-IOV 的 NIC 存在于 numa0 上。可用于 pod 调度的 CPU 仅存在于 numa1 上。通过将 excludeTopology 规格设置为 true，拓扑管理器可将 pod 的 CPU 和内存资源分配给 numa1，并可将同一 pod 的 SR-IOV 网络资源分配给 numa0。只有将 excludeTopology 规格设置为 true 时，才能实现。否则，拓扑管理器会尝试将所有资源放在同一 NUMA 节点上。

18.2.5. SR-IOV 配置故障排除

在进行了配置 SR-IOV 网络设备的步骤后，以下部分会处理一些错误条件。

要显示节点状态，请运行以下命令：

$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>

其中： <node_name> 指定带有 SR-IOV 网络设备的节点名称。

错误输出：无法分配内存

"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"

当节点表示无法分配内存时，检查以下项目：

确认在 BIOS 中为节点启用了全局 SR-IOV 设置。
确认在 BIOS 中为该节点启用了 VT-d。