Linux sriov-network-device-plugin 的 VF 资源暴露与 DPDK pod 调度

根本原因是vf未绑定vfio-pci驱动；需确认sr-iov启用、手动绑定驱动、持久化配置，并确保dpdk pod正确挂载/dev/vfio及pci地址匹配。

VF 设备没出现在 /dev/vfio/ 下，DPDK pod 启动失败报 open /dev/vfio/xx: no such device

根本原因不是插件没装，而是 VF 没被正确绑定到 vfio-pci 驱动。sriov-network-device-plugin 只负责上报资源，不负责驱动绑定。

实操建议：

• 确认 VF 已启用：ip link show 看是否有 ens1f0v0 类似接口；再查 lspci -k -s $(lspci | grep Ethernet | grep -v Virtual | head -1 | awk '{print $1}') 看 kernel driver 是否为 vfio-pci
• 若显示 igb_uio 或 ixgbevf，需手动解绑重绑：echo 0000:82:00.1 > /sys/bus/pci/devices/0000:82:00.1/driver/unbind，再 echo 0000:82:00.1 > /sys/bus/pci/drivers/vfio-pci/bind
• 持久化绑定需写入 /etc/modprobe.d/vfio.conf：添加 options vfio-pci ids=8086:154c,8086:154d（用 lspci -n -s 0000:82:00.1 查 vendor:device ID）
• 注意：绑定 vfio-pci 后，VF 将无法作为常规网卡使用（ip link 不再可见），这是 DPDK 必要代价

sriov-network-device-plugin 报错 failed to list sriov network devices: no SR-IOV capable devices found

插件扫描的是 host 上已启用 SR-IOV 的 PF，不是 VF 数量，也不是是否创建了 NetworkAttachmentDefinition。

实操建议：

• 检查 PF 是否开启 SR-IOV：cat /sys/class/net/ens1f0/device/sriov_numvfs —— 值必须 > 0；若为 0，需先 echo N > sriov_numvfs（N ≤ max_vfs）
• 确认 PF 驱动支持 SR-IOV：ethtool -i ens1f0 | grep firmware，Intel 卡需 firmware ≥ 7.0，Mellanox 需 MLNX_OFED ≥ 5.0
• 某些云厂商（如 AWS EC2、azure HBv3）禁用 host 层 SR-IOV，插件必然扫不到 —— 此时不能硬上，得换用 ENA/EFA DPDK 驱动或放弃 VF 直通
• 插件默认只扫 net 子系统设备，若 PF 被移出 net 命名空间（如某些容器运行时异常），也会漏掉

DPDK pod 启动后 rte_eth_dev_count_avail() 返回 0

不是插件没暴露资源，而是 pod 没拿到 VF 的 vfio-pci 设备节点，或 DPDK 应用没用对 PCI 地址。

实操建议：

• 进 pod 执行 ls /dev/vfio/ —— 若为空，说明 device plugin 没成功挂载设备，检查 pod annotation：k8s.v1.cni.cncf.io/networks: '[{"name": "sriov-net", "Interface": "net1"}]' 和对应 NetworkAttachmentDefinition 中 resourceName 是否匹配插件配置的 resourcePrefix（如 intel.com/sriov_net）
• 确认 pod spec 中有 securityContext.privileged: true，且 volumeMounts 包含 /dev/vfio（插件自动注入，但若用了自定义 runtimeClass 或 seccomp，可能被拦截）
• DPDK 初始化时用的 PCI 地址必须和 lspci 在 pod 内看到的一致；别直接抄宿主机的地址 —— 容器内 PCI domain 可能不同，用 dpdk-devbind.py --status 看实际绑定情况
• DPDK 20.11+ 默认启用 IOMMU，若宿主机 BIOS 关闭 VT-d/AMD-Vi，或内核启动参数没加 iommu=pt intel_iommu=on，rte_eal_init 会静默失败

多个 DPDK pod 调度到同一节点，出现 VF 设备冲突或性能骤降

本质是资源隔离失效：VF 共享同一个 PF 的硬件队列和中断，且插件默认不校验 VF 分配唯一性。

实操建议：

• 在 SriovNetworkNodePolicy 中设置 deviceType: vfio-pci 并启用 isRdma: false（即使不用 RDMA，也建议显式声明），避免插件误把 VF 当成普通网络设备复用
• 给每个 VF 分配独立的 MSI-X vector（非共享），并在 pod annotation 中通过 pod.alpha.kubernetes.io/device-capabilities 传递中断亲和性要求（需配合 kubelet --feature-gates=DevicePlugins=true）
• 监控 ethtool -S ens1f0 | grep tx_queue_.*packets —— 若多个 pod 对应的 VF 出现 queue 0/1 严重倾斜，说明流量没均衡，需调 PF 的 DCB 或 VMDq 参数，而非只调 pod
• 最易忽略的一点：DPDK 应用若用 RTE_ETH_RX_OFFLOAD_CHECKSUM，而硬件校验和卸载未在 PF 层统一关闭（ethtool -K ens1f0 rx off tx off），会导致部分 VF 收包异常，现象是偶发丢包且无错误日志