DPDK L2Fwd应用跨PF的VF间通信吞吐量异常骤降问题排查求助

首先，从你的测试数据和环境来看，跨PF VF通信的吞吐量瓶颈大概率和PCIe链路带宽限制以及NUMA节点跨访问有关，下面给你拆解排查方向和优化建议：

一、先确认PCIe链路的实际可用带宽 #

你的服务器PCIe Hub是5GT/s x4的链路，理论带宽是5GT/s ×4 /8 = 2.5GB/s（约20Gbps），但这是双向总带宽。而跨PF通信时，流量的路径是：
外部→VF0（PF0）→PCIe链路→PF1的VF1→App2处理→VF2（PF1）→PCIe链路→PF0的VF1→App1处理→VF0→外部
相当于流量在PCIe链路上走了4次单向传输，再加上PCIe协议本身的开销，实际可用的有效带宽会明显打折扣。另外，X710的PF本身也会占用部分PCIe带宽处理管理报文，进一步压缩用户流量的可用空间。

你可以用lspci -vvv命令查看PF的PCIe链路实际协商速率和宽度，确认是否真的跑在5GT/s x4，有没有出现降速情况（比如链路宽度变成x2或者速率降到2.5GT/s）。

二、检查NUMA亲和性配置 #

你的服务器有2个NUMA节点，先确认两个PF分别绑定在哪个NUMA节点上：

• 用numactl -H或者lspci -n | grep 8086:1572（X710的vendor是8086，device是1572），再对应查找所属NUMA节点。
• 如果两个PF分属不同NUMA节点，而你的DPDK应用核心和内存大页没有绑定到对应节点，会导致跨NUMA访问内存，带来额外的延迟和带宽损耗。

优化建议：

• 将App1的核心和大页绑定到PF0所在的NUMA节点，App2的核心和大页绑定到PF1所在的NUMA节点，避免跨NUMA内存访问。
• 启动DPDK应用时，用--lcores和--socket-mem参数指定核心和内存节点，示例：

  ./l2fwd --lcores='0-1@0' --socket-mem=2048,0 -w 0000:08:00.0,vf=0 -w 0000:08:00.0,vf=1
  

  其中@0表示绑定到NUMA节点0，--socket-mem=2048,0表示给节点0分配2048MB大页。

三、排查VF的带宽限制 #

部分Intel网卡默认会给VF设置带宽限制，你可以通过PF的sysfs接口查看和调整：

• 查看VF的带宽限制：

  cat /sys/class/net/ens2f0/device/sriov_vf_total_bw
  cat /sys/class/net/ens2f0/device/sriov_vf_bw[0-3]
  

• 如果存在限制，将带宽调整到最大值（比如10Gbps）：

  echo 10000 > /sys/class/net/ens2f0/device/sriov_vf_bw0
  echo 10000 > /sys/class/net/ens2f1/device/sriov_vf_bw1
  

  注意需要先停止DPDK应用，调整后再重启。

四、优化DPDK应用的转发逻辑 #

你的模型2中，App1需要同时处理收发包和跨VF转发，可能存在线程调度瓶颈：

• 把App1的收包、转发、发包拆分到不同核心，比如用一个核心专门收VF0的流量，一个核心专门处理转发到VF1，另一个核心专门收VF1的回传流量并发到VF0，避免单个核心负载过高。
• 调整DPDK的队列配置，给每个VF分配多个收发包队列，绑定到不同核心，提升并行处理能力。

五、验证PCIe交换机的性能 #

如果你的服务器PCIe链路经过了外部PCIe交换机（而非主板集成Hub），可能交换机本身存在带宽瓶颈或转发延迟过高。可以尝试用DPDK的rte_ring在App1和App2之间共享内存实现转发（而非通过VF硬件转发），测试吞吐量是否提升——如果提升明显，说明问题确实出在PCIe硬件转发环节。

最后，双10G端口跨PF仅跑3.5Gbps肯定是不正常的，优先从NUMA亲和性和PCIe链路配置入手排查，这两个是此类问题最常见的诱因。

内容的提问来源于stack exchange，提问作者sharath shetty