2. 第2章
02 SR-IOV核心概念：PF、VF、VF LAG与物理功能管理
掌握SR-IOV核心概念在SR-IOV核心概念中的定位、故障信号与验证顺序。
排障先看这三点
- 先核对SR-IOV核心概念的前置条件、异常信号和验收结果
- 再用伪代码把实现动作固定下来
- 最后用稳定性与可观测性验证结果是否可复现
源码证据
SR-IOV核心概念只有在出现源码、函数、脚本或 API 证据时，才需要进入代码层核对。
本节把SR-IOV核心概念对应的调用关系、异常状态和复测证据放在一起检查。
从物理端口到虚拟网卡：PF与VF的创建与删除
SR-IOV核心概念的验收口径
在SR-IOV（Single Root I/O Virtualization）架构中，物理功能（Physical Function, PF）是管理实体，拥有完整的PCIe配置空间，负责控制物理端口和虚拟功能（Virtual Function, VF）的生命周期。VF是轻量级PCIe设备，拥有独立的收发队列和中断资源，但控制路径依赖PF。在Mellanox ConnectX系列网卡上，mlxconfig和mlxdevm是管理PF与VF的核心工具
创建VF的关键在于两步：首先确保BIOS和固件中启用了SR-IOV，然后通过mlxdevm命令动态分配VF数量。例如，在ConnectX-6 Dx网卡上，执行mlxdevm dev eswitch set pci/0000:03:00.0 mode switchdev将eswitch模式设置为switchdev，再执行echo 8 > /sys/class/net/ens1f0/device/sriov_numvfs即可创建8个VF。删除VF时，只需将0写入同一文件：echo 0 > /sys/class/net/ens1f0/device/sriov_numvfs。注意，删除前必须确保所有VF未被任何虚拟机或容器占用，否则操作会失败
创建VF后，立即检查ip link show确认VF接口状态。若VF未显示，使用dmesg | grep -i sriov查看内核日志，常见原因是PCIe ACS（Access Control Services）未关闭或BIOS中VT-d未启用
一个常见误区是认为PF与VF的MAC地址必须手动指定。实际上，Mellanox网卡支持自动生成VF MAC地址，但生产环境中建议通过ip link set ens1f0 vf 0 mac 00:11:22:33:44:55为每个VF绑定固定MAC，避免虚拟机迁移后网络中断。下表总结了PF与VF的核心参数差异：
| 时间/步骤 | 输入 | 动作 |
|---|---|---|
| PCIe配置空间 | 完整 | 精简（仅基础配置） |
| 管理能力 | 可创建/删除VF，配置eswitch | 无管理能力，依赖PF |
| 最大队列数 | 受物理端口限制（如ConnectX-6支持128队列） | 默认2-16队列，可通过 mlxconfig 调整 |
| MAC地址管理 | 物理端口MAC | 可独立设置，支持spoofchk |
不要试图在VF上执行mlxdevm命令。VF没有eswitch管理能力，所有eswitch规范必须在PF上配置。若误操作，系统会返回“Operation not supported”错误
VF LAG链路聚合：从原理到配置验证
VF LAG（Link Aggregation）允许将多个物理端口上的VF绑定为一个逻辑链路，实现负载均衡和故障切换。在Mellanox网卡上，VF LAG基于硬件eswitch实现，不依赖内核的bonding驱动。其核心原理是：PF将多个物理端口的上行链路聚合为一个逻辑组，VF的流量通过哈希算法（如源MAC、目的IP）分发到不同物理端口
配置VF LAG前，必须确保所有参与聚合的PF处于相同的eswitch模式（switchdev或legacy），且固件版本一致。典型配置步骤：首先在PF上启用LAG模式：mlxconfig -d /dev/mst/mt4123_pciconf0 set LAG_RESOURCE_ALLOCATION=1，然后重启网卡。接着，通过teamd或libteam创建聚合组，但Mellanox推荐直接使用mlxdevm的硬件LAG功能：mlxdevm dev eswitch set pci/0000:03:00.0 lag_mode hash。验证LAG状态的关键命令是mlxdevm dev eswitch show pci/0000:03:00.0，输出中应包含lag_mode hash和lag_ports 2
真实项目场景
某金融交易系统使用ConnectX-5双端口网卡，要求VF流量在两条10G链路上负载均衡。工程师配置VF LAG后，发现单条链路故障时流量中断。排查发现，lag_mode被误设为active-backup而非hash，导致故障切换依赖软件检测，延迟超过5秒。修正为hash模式后，切换时间降至毫秒级
VF LAG的故障排查重点在于检查eswitch规范和物理端口状态。使用mlxdevm dev eswitch show pci/0000:03:00.0查看LAG成员端口，确保所有端口状态为active。若某个端口显示inactive，检查链路层协商（ethtool ens1f0）和光模块兼容性。下表列出了VF LAG配置中的常见问题与修复动作：
VF LAG的哈希算法默认基于源MAC和目的IP。若流量模型单一（如所有流量发往同一网关），哈希结果可能集中到一条链路。此时应启用lag_hash_type参数，加入L4端口号作为哈希因子，实现更均匀的分布
物理功能管理：风险边界与判断标准
PF管理操作（如创建VF、修改eswitch模式）直接影响网络控制面，操作不当可能导致整个物理端口不可用。风险边界主要体现在三个方面：一是VF数量超过硬件限制（ConnectX-5最大支持256个VF，ConnectX-6支持1024个），超出后创建命令静默失败；二是eswitch模式切换（legacy到switchdev）会重置所有VF配置，必须在业务低峰期执行；三是VF LAG配置中，若误将不同速率的端口聚合（如10G与25G），会导致丢包率上升
判断PF管理操作是否安全的检查清单如下：
预防措施包括：在修改PF配置前，使用mlxdevm dev eswitch backup导出当前eswitch规范；操作后立即执行ip link show和mlxdevm dev eswitch show验证状态。若出现PF无响应，兜底方案是重启网卡（mlxfwreset -d /dev/mst/mt4123_pciconf0 reset），但此操作会导致所有VF中断，需提前通知业务方
每次修改PF配置后，记录mlxdevm dev eswitch show的输出到日志文件。当故障发生时，对比前后配置差异，可快速定位是VF数量变化还是LAG模式变更导致的问题