PcapPlusPlus DPDKFilterTraffic性能未达预期，是否配置有误？

AI 小北

2026-8-11

问题描述

环境配置

硬件：Mellanox ConnectX-5网卡
系统：Ubuntu 22.04.01
DPDK/PcapPlusPlus：最新版本
内核：5.15.0-53-generic
大页：10个1GB大页

网卡详细信息

Device #1:
----------

  Device Type:      ConnectX5
  Part Number:      MCX516A-CCA_Ax
  Description:      ConnectX-5 EN network interface card; 100GbE dual-port QSFP28; PCIe3.0 x16; tall bracket; ROHS R6
  PSID:             MT_0000000012
  PCI Device Name:  /dev/mst/mt4119_pciconf0
  Base GUID:        b8cef60300fb1330
  Base MAC:         b8cef6fb1330
  Versions:         Current        Available     
     FW             16.35.1012     N/A           
     PXE            3.6.0804       N/A           
     UEFI           14.28.0015     N/A           

  Status:           No matching image found

网卡链路配置（ethtool输出）

Settings for ens7f0np0:
        Supported ports: [ Backplane ]
        Supported link modes:   1000baseKX/Full
                                10000baseKR/Full
                                40000baseKR4/Full
                                40000baseCR4/Full
                                40000baseSR4/Full
                                40000baseLR4/Full
                                25000baseCR/Full
                                25000baseKR/Full
                                25000baseSR/Full
                                50000baseCR2/Full
                                50000baseKR2/Full
                                100000baseKR4/Full
                                100000baseSR4/Full
                                100000baseCR4/Full
                                100000baseLR4_ER4/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: None        RS      BASER
        Advertised link modes:  100000baseKR4/Full
                                100000baseSR4/Full
                                100000baseCR4/Full
                                100000baseLR4_ER4/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: No
        Advertised FEC modes: RS
        Speed: 100000Mb/s
        Duplex: Full
        Auto-negotiation: off
        Port: Direct Attach Copper
        PHYAD: 0
        Transceiver: internal
netlink error: Operation not permitted
        Current message level: 0x00000004 (4)
                               link
        Link detected: yes

测试场景与问题

tcpdump单端口测试

执行命令：

sudo tcpdump -i ens7f0np0 udp -nn -# -N -B 1048576 -t -q -Q in -p -w /mnt/md0/test/test.pcap dst port 50340

1秒测试生成2GB pcap文件，符合预期；但双端口采集时内核无法处理，出现丢包，因此转向DPDK方案。

PcapPlusPlus DpdkTrafficFilter测试

执行命令：

sudo ./DpdkTrafficFilter -d 2 -f /mnt/md0/ -o 'UDP' -c 7

输出日志：

EAL: Detected CPU lcores: 56
EAL: Detected NUMA nodes: 2
EAL: Detected shared linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: No available 2048 kB hugepages reported
EAL: VFIO support initialized
EAL: Probe PCI driver: mlx5_pci (15b3:1015) device: 0000:17:00.0 (socket 0)
mlx5_net: No available register for sampler.
EAL: Probe PCI driver: mlx5_pci (15b3:1015) device: 0000:17:00.1 (socket 0)
mlx5_net: No available register for sampler.
EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: 0000:31:00.0 (socket 0)
EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: 0000:31:00.1 (socket 0)
EAL: Probe PCI driver: mlx5_pci (15b3:1015) device: 0000:b1:00.0 (socket 1)
mlx5_net: No available register for sampler.
EAL: Probe PCI driver: mlx5_pci (15b3:1015) device: 0000:b1:00.1 (socket 1)
mlx5_net: No available register for sampler.
EAL: Probe PCI driver: mlx5_pci (15b3:1015) device: 0000:ca:00.0 (socket 1)
mlx5_net: No available register for sampler.
EAL: Probe PCI driver: mlx5_pci (15b3:1015) device: 0000:ca:00.1 (socket 1)
mlx5_net: No available register for sampler.
EAL: Probe PCI driver: mlx5_pci (15b3:1015) device: 0000:e3:00.0 (socket 1)
mlx5_net: No available register for sampler.
EAL: Probe PCI driver: mlx5_pci (15b3:1015) device: 0000:e3:00.1 (socket 1)
mlx5_net: No available register for sampler.
TELEMETRY: No legacy callbacks, legacy socket not created
Opened device #2 with 1 RX queues and 1 TX queues. RSS hash functions:
   RSS_IPV4
   RSS_IPV6
Using core 1
   Core configuration:
      DPDK device#2: RX-Queue#0;  
Using core 2
   Core configuration:
      None
^C
Application stopped
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Core ID | Packet Cnt  | Eth Cnt     | ARP Cnt     | IPv4 Cnt    | IPv6 Cnt    | TCP Cnt     | UDP Cnt     | HTTP Cnt    | Matched TCP Flows  | Matched UDP Flows  | Matched Packets    |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 1       | 514051      | 514051      | 0           | 514051      | 0           | 0           | 514051      | 0           | 0                  | 1                  | 514050             |
| 2       | 0           | 0           | 0           | 0           | 0           | 0           | 0           | 0           | 0                  | 0                  | 0                  |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Total   | 514051      | 514051      | 0           | 514051      | 0           | 0           | 514051      | 0           | 0                  | 1                  | 514050             |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

1秒测试仅生成725MB pcap文件，远低于预期，且性能不如tcpdump。已修改代码设置MTU为9000，但无改善。

疑问：

配置哪里有误？
是否存在丢包？
为何性能不如tcpdump？

问题分析与解决方案

1. 性能差异与丢包原因

（1）RX队列与CPU核绑定瓶颈

从日志可见，仅给DPDK设备分配了1个RX队列，且仅绑定到1个CPU核（core 1），core 2完全闲置。对于100Gbps链路+9000字节MTU的流量，单队列单核的处理能力会被打满：

9000字节UDP包的理论最大吞吐量约为1.38Mpps，但单CPU核的实际包处理能力通常在1Mpps以内，测试中仅处理了~514kpps，说明单核已过载，导致网卡侧丢包。

（2）大页配置不匹配

日志显示EAL: No available 2048 kB hugepages reported，虽然配置了1GB大页，但DPDK默认优先尝试2MB大页，内存分配效率降低会间接影响性能。

（3）示例程序的额外开销

DpdkTrafficFilter包含协议解析、流量匹配逻辑，这些额外操作会占用CPU资源，相比tcpdump的极简抓包逻辑，开销更大，导致性能下降。

（4）NUMA亲和性未优化

系统有2个NUMA节点，但当前配置未将DPDK设备、大页、CPU核绑定到同一NUMA节点，跨NUMA访问会增加内存延迟，降低处理效率。

2. 具体调整建议

（1）增加RX队列并绑定多CPU核

给每个端口分配2-4个RX队列，将每个队列绑定到同NUMA节点的空闲CPU核。修改代码或启动参数，调整队列数量与核绑定关系。

（2）强制使用1GB大页

启动DPDK应用时添加参数：

--huge-dir /dev/hugepages-1GB

避免2MB大页缺失的问题，提升内存分配效率。

（3）优化写文件逻辑

采用多线程分队列写文件，或批量写入（攒够一定数量的包再写入磁盘），减少磁盘IO的系统调用开销。
跳过不必要的协议解析：如果仅需保存payload，直接写入原始包数据，去掉协议解析步骤。

（4）配置NUMA亲和性

将大页分配到网卡所在NUMA节点（以socket 0为例）：

echo 10 > /sys/devices/system/node/node0/hugepages/hugepages-1048576kB/nr_hugepages

启动应用时指定NUMA节点与同节点CPU核：
```
--numa-socket-num 0 -l 1-4
```

（5）检查网卡丢包统计

使用dpdk-testpmd工具确认网卡侧丢包：

sudo dpdk-testpmd -l 1-4 -n 4 -- --portmask=0x2 --rxq=4 --txq=4 --stats-period=1

在testpmd中输入start收包，一段时间后输入show port stats all查看丢包情况。

3. 验证调整效果

调整后重新测试，对比每秒生成的pcap文件大小，同时观察CPU使用率、网卡丢包统计，确认瓶颈是否解除。

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

PcapPlusPlus DPDKFilterTraffic性能未达预期，是否配置有误？

环境配置 #

网卡详细信息 #

网卡链路配置（ethtool输出） #

测试场景与问题 #

tcpdump单端口测试 #

PcapPlusPlus DpdkTrafficFilter测试 #

1. 性能差异与丢包原因 #

（1）RX队列与CPU核绑定瓶颈 #

（2）大页配置不匹配 #

（3）示例程序的额外开销 #

（4）NUMA亲和性未优化 #

2. 具体调整建议 #

（1）增加RX队列并绑定多CPU核 #

（2）强制使用1GB大页 #

（3）优化写文件逻辑 #

（4）配置NUMA亲和性 #

（5）检查网卡丢包统计 #

3. 验证调整效果 #