众所周知，单个 PF 可以映射到多个 VF。
关于单个 PF 关联的 VF 数量：
在 PCIe 5.0 规范中：
实施说明
跨多个总线号码的 VF
作为示例，请考虑支持单个 PF 的 SR-IOV 设备。最初，仅 PF 0 可见。软件设置了 ARI 能力的层次结构。根据 SR-IOV 扩展功能，它确定：InitialVFs 为 600，First VF Offset 为 1，VF Stride 为 1。
如果软件将 NumVF 设置在 [0 … 255] 范围内，则设备使用单个总线编号。
如果软件将 NumVF 设置在 [256 … 511] 范围内，则设备使用两个总线编号。
如果软件将 NumVF 设置在 [512 … 600] 范围内，则设备使用三个总线编号。
PF 0 和 VF 0,1 到 VF 0,255 始终位于第一个（捕获的）总线编号上。 VF 0,256 到 VF 0,511 始终位于第二个总线编号上（捕获的总线编号加 1）。 VF 0,512 到 VF 0,600 始终位于第三个总线编号上（捕获的总线编号加 2）。
来自Oracle：
每个 SR-IOV 设备都可以有一个物理功能，每个物理功能最多可以有 64,000 个与其关联的虚拟功能。
从“共享 PCIe I/O 带宽”的角度来看，可以理解有数百或数千个 VF（与单个 PF 关联），每个 VF 分配给一个 VM，假设大多数 VF在特定时间点处于空闲状态；
但是，从“芯片制造”的角度来看，对于不重要的 PCIe 功能，在单个芯片内复制数百或数千个 IP 实例的 VF 部分会使芯片面积太大而不实用。
所以我的问题是，正如主题行中所述，是否有将如此多的 VF 与单个 PF 关联的实际用例？
当服务器用于运行虚拟机时，使用由 Hypervisor 模拟的半虚拟化网络接口是最简单的，但到目前为止不是最有效的解决方案。因此，当 VM guest 虚拟机需要高性能网络接口时，会使用 SR-IOV 方法，即物理网卡公开许多虚拟功能 (VF)，而虚拟机管理程序将这些 VF 中的一个或多个作为完整的虚拟功能公开给每个 VM。 PCI 设备。从那时起，VM guest 虚拟机就可以直接访问为分配的 VF 划分的网卡硬件资源。通常，单个 VM 来宾需要的不仅仅是一个网络接口，就像充当路由器或防火墙的虚拟设备的情况一样。此类 VF 代表物理网卡的碎片，通常称为“vNIC”（虚拟网络接口卡）或“ENA”（在 AWS 中为弹性网络适配器）。 所需的此类 vNIC（以及 VF）数量与服务器应支持的 VM 数量成正比，在具有 2 个插槽、每个具有超线程技术的 64 个 CPU 核心的服务器上，可以达到 256 个来宾 - 每个 VM 2 个 vNIC平均而言，VF的数量将达到1000个。 如果服务器旨在支持容器（例如 Kubernetes），那么比成熟的虚拟机更轻可以允许服务器上有更多容器，这与高性能网络的要求相结合，即 SR-IOV（直接容器访问网络）卡硬件队列），意味着需要支持数千个 VF。
在实现方面，Synopsis 发表了一篇文章解决您关心的触发器计数挑战，他们建议使用 SRAM 来存储 PCIe 设备的配置空间，而不是直接触发器。