02 SR-IOV硬件原理：PF、VF与PCIe直通机制

🧭SR-IOV 硬件隔离与数据路径：从物理网卡到容器网卡

在 Kubernetes（K8s）集群中运行高性能网络应用（如 NFV、AI 训练、高频交易）时，通用虚拟网卡（如 veth、bridge）因软件模拟开销导致延迟抖动和吞吐瓶颈。SR-IOV（Single Root I/O Virtualization）通过硬件直通解决此问题，其核心在于理解物理功能（Physical Function, PF）与虚拟功能（Virtual Function, VF）的隔离机制与数据路径

🎯问题定位：软件虚拟化瓶颈与硬件直通目标

传统容器网络模型中，每个数据包需经过宿主内核的 Bridge、iptables、路由表，再通过软件中断（SoftIRQ）送达容器。此路径在 10Gbps 以上带宽时，CPU 占用率飙升，延迟可达 50-100μs。SR-IOV 的目标是：消除软件介入，让容器直接操作硬件队列

关键对象 Kubernetes（K8s） 在此场景中作为编排层，需通过 kubelet 和 device plugin 将 VF 分配给 Pod。若硬件隔离不彻底（如 VF 之间共享 DMA 通道），会导致租户数据泄露或性能干扰

🧠关键机制：PF

一张支持 SR-IOV 的网卡（如 Intel XXV710、Mellanox ConnectX-5）在硬件上被划分为一个 PF 和多个 VF。PF 是标准 PCIe 功能，拥有完整配置空间，负责链路管理、VF 创建/销毁、MAC/VLAN 过滤规范下发。VF 是轻量级 PCIe 功能，仅包含数据收发所需的队列和寄存器，不参与物理层管理

数据路径：硬件交换而非软件转发

当容器通过 VF 发送数据时，数据流如下：

1. 容器内应用写入 VF 的 DMA 描述符
2. 网卡硬件直接从 VF 对应的内存区域读取数据，封装成帧
3. 网卡内部交换引擎根据 MAC/VLAN 表决定转发到外部网络或另一个 VF
4. 接收方向：网卡根据 RSS（Receive Side Scaling）或 Flow Director 规范，将数据直接 DMA 到目标 VF 的内存，无需宿主 CPU 参与

此路径中，PF 仅作为控制面，不参与数据转发。若 PF 驱动异常或 VF 数量超限（如 Intel 700 系列最多 64 VF），会导致 VF 创建失败或性能下降