简介：《DPDK Testpmd 应用》PDF 用户指南面向从事高速数据包转发开发与性能调优的工程师，以及希望基于 DPDK SDK 构建完整应用的开发者。文档围绕 testpmd 这一 Packet Forwarding 示例程序展开，讲解如何编译、运行该应用，并借助命令行选项与运行时函数访问 Flow Director 等网卡硬件特性。内容涵盖 EAL 环境抽象层、Packet Framework 处理框架与 NIC Poll Mode Driver 三部分架构，并系统梳理帮助、控制、显示、配置、端口、链路绑定、寄存器及过滤等运行时函数，可作为理解 DPDK 基本概念与二次开发的参考。资源为单个 PDF 文件，压缩包约 137KB，篇幅精炼、目录清晰，便于按章节检索查阅。目前已有 599 人学习下载，适合需要快速上手 testpmd、对照官方文档排查转发配置问题的读者。
1. 从抓包到打流：为什么我建议每个网络性能工程师都啃一遍《DPDK Testpmd 应用》
如果你做过网络数据面性能测试，大概率经历过这样的场景：用 iperf3 跑出来的数字和硬件标称值差了一大截，换了几组参数还是上不去，最后发现瓶颈根本不在被测设备，而在测试工具本身。这种时候，你需要的是一个能绕过内核协议栈、直接操作网卡收发包的工具，而 DPDK 的 testpmd 就是这个角色。这份《DPDK Testpmd 应用》PDF 讲的就是怎么用 testpmd 做二层转发、收发包统计、流规则配置和性能验证。它适合已经了解 DPDK 基本概念、需要动手搭测试环境的数据面工程师、网卡驱动开发者和性能调优人员。不是入门读物，但如果你手头有 Intel 82599、X710 或者 Mellanox 系列网卡，想跑出线速转发或者定位丢包点，这份材料能帮你省掉大量翻源码的时间。
2. 先搞清楚 testpmd 到底在干什么：从 EAL 初始化到转发引擎
2.1 testpmd 的定位与核心能力边界
testpmd 是 DPDK 自带的一个命令行测试应用，编译完 DPDK 之后在build/app/目录下就能找到。它的本质是一个跑在 DPDK EAL 之上的二层转发程序，支持三种转发模式：IO 模式（收包后直接丢弃或回显）、MAC 模式（根据目的 MAC 地址转发）、以及基于流规则的转发。很多人第一次用 testpmd 会把它当成一个简单的打流工具，但实际上它更像一个可编程的数据面测试框架——你可以通过命令行动态添加流规则、修改队列数量、调整描述符环大小，甚至挂载自己的转发回调。
它的能力边界也很清晰：testpmd 不处理 TCP/IP 协议栈，不做路由查找，不维护 ARP 表。它只关心以太网帧的收发和转发。这意味着如果你要测试的是三层转发性能，testpmd 只能帮你验证到二层，三层以上的逻辑需要自己写应用或者用其他工具配合。但反过来，正因为它的逻辑足够简单，才能把 CPU 和网卡的开销压到最低，测出来的数字更接近硬件极限。
这份 PDF 在开篇部分花了相当篇幅讲 EAL 初始化参数，这是有道理的。testpmd 的所有行为都建立在 EAL 正确初始化的基础上，如果-l核心绑定、-n内存通道数、--socket-mem这些参数没设对，后面怎么调都是白费。我见过太多人一上来就敲testpmd -l 0-3 -n 4，结果跑出来性能还不如内核转发，问题就出在没理解 EAL 的内存和核心分配逻辑。
2.2 编译与运行环境搭建
在跑 testpmd 之前，DPDK 本身得先编译通过。常见做法是先用meson和ninja构建，然后设置大页内存和网卡绑定。下面这套命令是我在 CentOS 7.9 + Intel X710 环境下反复用过的，可以直接抄。
# 克隆 DPDK 源码（假设已经下载了对应版本的 tar 包） tar xf dpdk-22.11.tar.xz cd dpdk-stable-22.11.1 # 用 meson 构建，指定安装前缀 meson setup build --prefix=/usr/local/dpdk ninja -C build ninja -C build install # 设置大页内存，2MB 页，分配 2048 个 echo 2048 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages # 挂载 hugetlbfs mkdir -p /mnt/huge mount -t hugetlbfs nodev /mnt/huge # 绑定网卡到 vfio-pci 驱动 modprobe vfio-pci dpdk-devbind.py --bind=vfio-pci 0000:3b:00.0 dpdk-devbind.py --bind=vfio-pci 0000:3b:00.1 # 确认绑定状态 dpdk-devbind.py --status这里有几个参数需要解释。--prefix指定安装路径，后面编译 testpmd 时会从PKG_CONFIG_PATH里找 DPDK 的.pc文件。大页内存的数量取决于你要跑几个队列、每个队列的收发描述符环有多大，2048 个 2MB 页是 4GB，对于两个万兆口、每口 4 队列的场景基本够用。vfio-pci比igb_uio更推荐，因为它在内核主线里，不需要额外打补丁，而且支持 IOMMU 保护。
绑定完网卡之后，用dpdk-devbind.py --status应该能看到网卡从Kernel driver in use: ixgbe变成了Kernel driver in use: vfio-pci。如果这一步失败，先检查 BIOS 里 VT-d 和 IOMMU 有没有开，再看dmesg里有没有vfio: no IOMMU之类的报错。
2.3 testpmd 启动参数逐项拆解
环境就绪后，启动 testpmd 的命令行参数决定了它的行为模式。下面这条命令是我常用的基准配置：
./build/app/dpdk-testpmd \ -l 0-3 \ -n 4 \ --socket-mem 1024,1024 \ -a 0000:3b:00.0 \ -a 0000:3b:00.1 \ -- \ --rxq=4 \ --txq=4 \ --rxd=1024 \ --txd=1024 \ --forward-mode=mac \ --eth-peer=0,00:11:22:33:44:55 \ --eth-peer=1,00:11:22:33:44:56 \ --stats-period=1-l 0-3表示用 0 到 3 号逻辑核，其中 0 号核通常跑主线程做管理，1 到 3 号核跑转发。-n 4是内存通道数，现代服务器一般是 4 或 8，设错了会影响内存带宽。--socket-mem 1024,1024表示两个 NUMA 节点各分配 1GB 大页内存，如果机器只有一个 NUMA 节点，写--socket-mem 1024就行。
--后面的参数是 testpmd 应用层参数。--rxq=4和--txq=4表示每个网口 4 个收发队列，队列数一般不要超过绑定的转发核数，否则会有队列抢不到核。--rxd和--txd是描述符环大小，1024 是常用值，调到 2048 或 4096 能提高突发容忍度，但会占用更多内存。--forward-mode=mac指定 MAC 转发模式，--eth-peer手动指定目的 MAC 地址，避免依赖 ARP。--stats-period=1让 testpmd 每秒打印一次统计信息，调试时很有用。
启动之后你会看到类似这样的输出：
EAL: Detected 32 lcore(s) EAL: Detected 2 NUMA nodes EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'VA' EAL: Probing VFIO support... EAL: PCI device 0000:3b:00.0 on NUMA socket 0 EAL: probe driver: 8086:1572 net_ixgbe Port 0: 00:11:22:33:44:55 Port 1: 00:11:22:33:44:56 Checking link statuses... Port 0 Link up at 10 Gbps Port 1 Link up at 10 Gbps testpmd>看到testpmd>提示符就说明启动成功了。这时候输入start开始转发，stop停止，quit退出。show port stats all可以看每个口的收发包计数和丢包统计。
3. 转发模式与流规则：把 testpmd 用出生产级效果
3.1 MAC 转发与 IO 转发的选择依据
testpmd 的--forward-mode支持好几种模式，最常用的是io和mac。io模式最简单：从哪个口收的包，直接从同一个口发回去，或者按配置丢弃。它适合做环回测试，比如你用一个打流仪往口 0 发包，testpmd 在口 0 收包后直接回发，打流仪就能测出往返时延和丢包率。
mac模式则是在收包后查一张 MAC 地址表，决定从哪个口转发出去。这张表可以通过--eth-peer参数静态配置，也可以在运行时用add_peer命令动态添加。比如：
testpmd> add_peer 0 00:11:22:33:44:55 testpmd> add_peer 1 00:11:22:33:44:56这两条命令的意思是：从口 0 收到的、目的 MAC 为00:11:22:33:44:55的包，转发到口 1；从口 1 收到的、目的 MAC 为00:11:22:33:44:56的包，转发到口 0。这样就形成了一个双向转发路径。
选io还是mac取决于你的测试目标。如果只是测网卡收发包性能，io模式开销最小，数字最干净。如果要模拟一个真实的二层转发设备，比如交换机或网桥，那就用mac模式。PDF 里还提到了txonly和rxonly模式，前者只发包不收包，后者只收包不转发，分别用于单向打流和纯收包测试。
3.2 流规则配置：从 rte_flow 到 testpmd 命令
testpmd 真正强大的地方在于它支持rte_flow流规则。你可以用命令行添加精确匹配、通配匹配、带动作的流表项，把特定流量引导到特定队列或者直接丢弃。这在做 QoS 测试、ACL 验证或者流量镜像时非常有用。
下面是一个典型的流规则示例，作用是：把从口 0 收到的、目的 IP 为192.168.1.100的 TCP 包，转发到队列 2。
testpmd> flow create 0 ingress pattern eth / ipv4 dst is 192.168.1.100 / tcp / end actions queue index 2 / end这条命令的语法结构是flow create <port_id> <方向> pattern <匹配项> actions <动作>。ingress表示入方向，pattern后面跟匹配链，actions后面跟动作。匹配链里eth / ipv4 dst is ... / tcp / end表示从以太网头开始逐层解析，end表示匹配链结束。动作queue index 2表示把匹配到的包送到队列 2。
如果要丢弃匹配的包，动作改成drop：
testpmd> flow create 0 ingress pattern eth / ipv4 src is 10.0.0.1 / end actions drop / end添加完流规则后，可以用flow list 0查看口 0 上所有规则，flow flush 0清空所有规则。需要注意的是，不同网卡对rte_flow的支持程度不一样。Intel 82599 支持基本的五元组匹配，X710 支持更丰富的匹配域，Mellanox 系列则支持硬件卸载的流表。如果添加规则时报ENOTSUP，说明网卡或驱动不支持这个匹配项，需要查一下对应网卡的流规则能力文档。
3.3 多队列与 RSS 配置
多队列是发挥多核性能的关键。testpmd 启动时用--rxq和--txq指定队列数，但队列和 CPU 核的绑定关系需要额外配置。默认情况下，testpmd 会把队列均匀分配到转发核上，但你可以用--rxq和--txq配合--nb-cores来精确控制。
RSS（接收端缩放）是把流量分散到多个队列的硬件机制。testpmd 默认会启用 RSS，基于 IP 五元组做哈希。你可以用下面的命令查看和修改 RSS 配置：
testpmd> show port 0 rss-hash testpmd> port config 0 rss-hash key 6d5a56da255b0ec24167253d43a38d9b... testpmd> port config 0 rss-hash ipv4-tcp第一条命令查看当前的 RSS 哈希 key 和生效的协议类型。第二条命令设置自定义哈希 key，这个 key 是 40 字节的十六进制串，通常由网卡厂商提供推荐值。第三条命令指定只对 IPv4 TCP 流做 RSS，其他流量都送到队列 0。
RSS 配置不当是导致性能不达标的常见原因。比如你明明开了 4 个队列，但所有流量都哈希到同一个队列，那另外 3 个核就在空转。这时候可以用show port stats all看每个队列的收包计数，如果某个队列的计数远高于其他队列，说明哈希分布不均匀。解决办法是调整 RSS key 或者改用--rss-ip只基于 IP 做哈希，减少哈希冲突。
4. 避坑与排查：testpmd 跑不起来时先看这几条
4.1 大页内存分配失败
现象：启动 testpmd 时报EAL: No free hugepages reported in hugepages-2048kB，或者EAL: Cannot allocate memory。
原因：大页内存没有预留，或者预留了但被其他进程占用。常见情况是之前跑过其他 DPDK 应用没正常退出，大页没释放。
解决：先cat /proc/meminfo | grep Huge看HugePages_Free是不是 0。如果是 0，检查/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages的值，重新写入需要的数量。如果写入后HugePages_Free还是 0，可能是内存碎片化导致分配不到连续大页，重启机器是最干脆的办法。另外确认hugetlbfs挂载参数里没有size=限制。
4.2 网卡绑定后无法启动
现象：dpdk-devbind.py --bind=vfio-pci执行成功，但 testpmd 启动时报EAL: Failed to attach device或Port 0: Link down。
原因：IOMMU 没开，或者网卡被内核驱动占着没完全解绑。有时候--bind成功了，但dmesg里能看到vfio-pci: probe of 0000:3b:00.0 failed。
解决：先确认 BIOS 里VT-d和IOMMU都开了。然后在 Linux 启动参数里加intel_iommu=on iommu=pt，重启后dmesg | grep -i iommu应该能看到 IOMMU 启用的日志。如果还是不行，试试用igb_uio替代vfio-pci，虽然不如 vfio 安全，但兼容性更好。另外检查网卡是不是被NetworkManager或者ifconfig管着，先ifconfig ethX down再绑定。
4.3 转发性能远低于预期
现象：两个万兆口跑 MAC 转发，show port stats all显示收发包速率只有 2-3 Gbps，远低于线速。
原因：可能是核心绑定不对、内存通道数设错、或者队列数太少。还有一种容易被忽略的情况：NUMA 节点不匹配。网卡插在 CPU 0 的 PCIe 槽上，但 testpmd 用的内存是从 CPU 1 的 NUMA 节点分配的，跨节点访问内存导致延迟飙升。
解决：先用lscpu和numactl -H确认网卡所在的 NUMA 节点。然后启动 testpmd 时用--socket-mem确保对应节点有足够大页，并且用-l绑定同节点的 CPU 核。比如网卡在 NUMA 0，就用-l 0-3 --socket-mem 1024,0。另外把--rxd和--txd从 1024 调到 2048，给突发流量更多缓冲。如果还是上不去，检查是不是开了--txq但没开--rxq，或者 RSS 没生效导致单队列瓶颈。
4.4 流规则添加失败
现象：flow create命令返回Caught error type 2 (flow rule): Invalid argument或者ENOTSUP。
原因：匹配项或动作不被网卡支持，或者语法写错了。比如在 82599 上试图匹配vxlan字段，硬件根本不支持 VXLAN 解析。
解决：先用flow list 0看当前规则，确认没有冲突。然后查网卡的rte_flow支持矩阵，Intel 网卡可以看 DPDK 文档里的ixgbe或i40e流规则章节。如果只是做简单五元组匹配，尽量用eth / ipv4 / tcp这种基础组合，避免用扩展字段。另外注意pattern链必须以end结尾，actions链也是，少写一个end就会报语法错误。
4.5 统计计数不更新
现象：show port stats all里的收发包计数一直不变，但打流仪显示有流量进来。
原因：testpmd 没有start，或者转发核被阻塞了。还有一种情况是网卡开了rx但没开tx，包收上来之后直接丢了，计数只加在rx上。
解决：先确认提示符下输入了start。如果已经start了，用show port stats all看RX-packets和TX-packets是不是都在涨。如果只有RX涨TX不涨，检查--forward-mode是不是设成了rxonly。另外用top -H看转发核的 CPU 占用率，如果某个核 100% 但计数不涨，可能是流规则把包都drop了，用flow list确认一下。
5. 进阶技巧：用 testpmd 做精确性能验证与自动化
5.1 用--stats-period和--display-xstats做细粒度观测
testpmd 默认的统计信息比较粗，只有收发包总数和字节数。但如果你在启动参数里加上--display-xstats，就能看到网卡硬件扩展统计，包括每个队列的丢包原因、CRC 错误、长度错误等。这些信息在定位物理层问题时非常关键。
./build/app/dpdk-testpmd -l 0-3 -n 4 -a 0000:3b:00.0 -a 0000:3b:00.1 \ -- --rxq=4 --txq=4 --forward-mode=mac --stats-period=1 --display-xstats启动后show port xstats 0会打印出几十项硬件计数器。我一般重点关注rx_queue_0_drop_packets、rx_queue_0_errors、tx_queue_0_errors这几项。如果drop_packets在涨，说明描述符环满了，需要加大--rxd或者减少打流速率。如果errors在涨，可能是光模块或者线缆有问题。
5.2 用--auto-start和脚本做批量测试
手动敲start和stop做几轮测试还行，但如果要跑几十组参数对比，手动操作就太慢了。testpmd 支持--auto-start参数，启动后自动开始转发，省掉一次交互。配合--stats-period和重定向输出，可以写一个简单的批量测试脚本：
#!/bin/bash # 批量测试不同队列数下的转发性能 for rxq in 1 2 4 8; do echo "=== Testing rxq=$rxq ===" timeout 30 ./build/app/dpdk-testpmd \ -l 0-7 -n 4 \ -a 0000:3b:00.0 -a 0000:3b:00.1 \ -- \ --rxq=$rxq --txq=$rxq \ --rxd=2048 --txd=2048 \ --forward-mode=mac \ --auto-start \ --stats-period=5 \ 2>&1 | tee testpmd_rxq${rxq}.log sleep 2 done这个脚本会依次用 1、2、4、8 个队列跑 30 秒，每次的统计输出存到单独日志里。跑完之后用grep提取TX-packets和RX-packets做对比，就能看出队列数对性能的影响曲线。注意timeout 30是必须的，因为 testpmd 不会自己退出，得靠外部信号杀掉。
5.3 验证转发正确性的一个笨办法
性能数字好看不代表转发逻辑正确。我习惯在跑完性能测试后，用一个小流量的精确测试验证转发路径。具体做法是：用scapy构造几个特定目的 MAC 的包，从口 0 发进去，然后在口 1 抓包，确认包的内容和数量都对得上。
from scapy.all import Ether, IP, UDP, sendp # 构造一个目的 MAC 为 00:11:22:33:44:55 的包 pkt = Ether(dst="00:11:22:33:44:55", src="aa:bb:cc:dd:ee:ff") / \ IP(src="10.0.0.1", dst="10.0.0.2") / \ UDP(sport=1234, dport=5678) / b"test_payload" # 从 eth0 发出去（eth0 是接在口 0 上的另一台机器） sendp(pkt, iface="eth0", count=10, inter=0.1)然后在口 1 对应的机器上用tcpdump抓包，确认收到 10 个包，且内容一致。这个办法虽然笨，但能发现很多性能测试掩盖的问题，比如 MAC 表配错了、流规则把包误丢了、或者 VLAN 标签被意外剥离。从那以后我每次跑完性能测试，都会强制走一遍这个小流量验证，确认转发路径没毛病再出报告。
希望这份笔记能帮你在下次搭 DPDK 测试环境时少走点弯路。
本文还有配套的精品资源，点击获取
