尧图网页设计 
简介《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 --bindvfio-pci 0000:3b:00.0 dpdk-devbind.py --bindvfio-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 \ -- \ --rxq4 \ --txq4 \ --rxd1024 \ --txd1024 \ --forward-modemac \ --eth-peer0,00:11:22:33:44:55 \ --eth-peer1,00:11:22:33:44:56 \ --stats-period1-l 0-3表示用 0 到 3 号逻辑核其中 0 号核通常跑主线程做管理1 到 3 号核跑转发。-n 4是内存通道数现代服务器一般是 4 或 8设错了会影响内存带宽。--socket-mem 1024,1024表示两个 NUMA 节点各分配 1GB 大页内存如果机器只有一个 NUMA 节点写--socket-mem 1024就行。--后面的参数是 testpmd 应用层参数。--rxq4和--txq4表示每个网口 4 个收发队列队列数一般不要超过绑定的转发核数否则会有队列抢不到核。--rxd和--txd是描述符环大小1024 是常用值调到 2048 或 4096 能提高突发容忍度但会占用更多内存。--forward-modemac指定 MAC 转发模式--eth-peer手动指定目的 MAC 地址避免依赖 ARP。--stats-period1让 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。如果要丢弃匹配的包动作改成droptestpmd 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 --bindvfio-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_iommuon iommupt重启后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 \ -- --rxq4 --txq4 --forward-modemac --stats-period1 --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 \ --rxd2048 --txd2048 \ --forward-modemac \ --auto-start \ --stats-period5 \ 21 | 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(dst00:11:22:33:44:55, srcaa:bb:cc:dd:ee:ff) / \ IP(src10.0.0.1, dst10.0.0.2) / \ UDP(sport1234, dport5678) / btest_payload # 从 eth0 发出去eth0 是接在口 0 上的另一台机器 sendp(pkt, ifaceeth0, count10, inter0.1)然后在口 1 对应的机器上用tcpdump抓包确认收到 10 个包且内容一致。这个办法虽然笨但能发现很多性能测试掩盖的问题比如 MAC 表配错了、流规则把包误丢了、或者 VLAN 标签被意外剥离。从那以后我每次跑完性能测试都会强制走一遍这个小流量验证确认转发路径没毛病再出报告。希望这份笔记能帮你在下次搭 DPDK 测试环境时少走点弯路。本文还有配套的精品资源点击获取 DPDK Testpmd 实战指南：从抓包到打流的性能测试与避坑
简介《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 --bindvfio-pci 0000:3b:00.0 dpdk-devbind.py --bindvfio-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 \ -- \ --rxq4 \ --txq4 \ --rxd1024 \ --txd1024 \ --forward-modemac \ --eth-peer0,00:11:22:33:44:55 \ --eth-peer1,00:11:22:33:44:56 \ --stats-period1-l 0-3表示用 0 到 3 号逻辑核其中 0 号核通常跑主线程做管理1 到 3 号核跑转发。-n 4是内存通道数现代服务器一般是 4 或 8设错了会影响内存带宽。--socket-mem 1024,1024表示两个 NUMA 节点各分配 1GB 大页内存如果机器只有一个 NUMA 节点写--socket-mem 1024就行。--后面的参数是 testpmd 应用层参数。--rxq4和--txq4表示每个网口 4 个收发队列队列数一般不要超过绑定的转发核数否则会有队列抢不到核。--rxd和--txd是描述符环大小1024 是常用值调到 2048 或 4096 能提高突发容忍度但会占用更多内存。--forward-modemac指定 MAC 转发模式--eth-peer手动指定目的 MAC 地址避免依赖 ARP。--stats-period1让 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。如果要丢弃匹配的包动作改成droptestpmd 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 --bindvfio-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_iommuon iommupt重启后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 \ -- --rxq4 --txq4 --forward-modemac --stats-period1 --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 \ --rxd2048 --txd2048 \ --forward-modemac \ --auto-start \ --stats-period5 \ 21 | 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(dst00:11:22:33:44:55, srcaa:bb:cc:dd:ee:ff) / \ IP(src10.0.0.1, dst10.0.0.2) / \ UDP(sport1234, dport5678) / btest_payload # 从 eth0 发出去eth0 是接在口 0 上的另一台机器 sendp(pkt, ifaceeth0, count10, inter0.1)然后在口 1 对应的机器上用tcpdump抓包确认收到 10 个包且内容一致。这个办法虽然笨但能发现很多性能测试掩盖的问题比如 MAC 表配错了、流规则把包误丢了、或者 VLAN 标签被意外剥离。从那以后我每次跑完性能测试都会强制走一遍这个小流量验证确认转发路径没毛病再出报告。希望这份笔记能帮你在下次搭 DPDK 测试环境时少走点弯路。本文还有配套的精品资源点击获取