DPDK testpmd: Packet Generator and Forwarding Modes

testpmd is DPDK's reference application and the first thing to run after binding a NIC to a poll-mode driver. It does two jobs at once: it proves the PMD binding, hugepages and core assignment are all correct, and it produces line-rate traffic for benchmarking. It is not, despite the name, a fully featured traffic generator out of the box — it will forward and it can transmit first, but it does not synthesise arbitrary packet streams. Knowing which of those you need saves a lot of confusion.

What testpmd Actually Does

In its default configuration testpmd forwards received packets back out, either on the same port or on a paired port. It supports several forwarding modes and can be driven interactively. If you want generated streams with defined payloads and rates, that is a different tool — but for validating that a NIC can sustain line rate, forwarding at wire speed is exactly the measurement you want.

Core and Port Masks

The two options that cause the most confusion are the core mask and the port mask, both of which are hex bitmasks:

• -c core mask — which lcores run the packet forwarding loop. The main lcore is reserved for command-line parsing and cannot be masked on for forwarding, so you always need at least two bits set.
• -w allowlist — which PCI devices to probe, in domain:bus:slot.func form.
• --portlist — an alternative to the port mask that takes a user-friendly list such as 0,1 or 0-3, where - denotes a range including both endpoints.
• --nb-cores — the number of forwarding cores, where 1 ≤ N ≤ the number of ports or RTE_MAX_ETHPORTS from the configuration file.

# Two forwarding cores, two ports, hugepages from mount point
dpdk-testpmd -l 2-3 -n 4 --huge-dir /dev/hugepages \
  -a 0000:03:00.0 -a 0000:03:00.1 \
  --nb-cores 2 --portlist 0-1 -- -i --forward-mode=io

Everything before the -- is EAL (environment abstraction layer) configuration: cores, memory channels, hugepages, devices. Everything after it belongs to the application.

Useful Application Options

-i, --interactive        Start in interactive shell instead of auto-forwarding
--auto-start             Start forwarding immediately at initialisation
--tx-first               Start forwarding after sending a burst of packets first
--nb-cores N             Number of forwarding cores
--portlist 0-1           Ports used for the forwarding test
--forward-mode=io        Receive on a port, transmit on the paired port
--forward-mode=rxonly    Receive and drop (pure receive benchmarking)
--forward-mode=txonly    Transmit only (synthetic traffic, no generator)
--forward-mode=mac       Swap MAC addresses and forward back out

--tx-first is the option to reach for when you need traffic on the wire without a peer sending anything: testpmd transmits a burst before entering the forwarding loop. Combined with --forward-mode=txonly it produces one-directional traffic, which is enough to measure a switch's forwarding rate or to bring a link up in a lab.

Interactive Commands

show port info all
show port stats all
show config fwd
start
stop
set verbose 1
set fwd io
set fwd rxonly
port start all / port stop all
clear port stats all

set verbose 1 prints one line per forwarded packet, which is invaluable for confirming a MAC or VLAN rewrite, and completely unusable for performance testing because it throttles throughput to the console.

Reading the Numbers Correctly

show port stats all reports RX/TX packets and bytes per port, plus RX/TX errors and misses. Three things to check before trusting a throughput figure:

• RX misses. A non-zero miss counter means packets were dropped because no descriptor was available — usually too few RX queues for the core count, or an undersized ring.
• Directionality. In io mode with paired ports, the transmit count on one port should track the receive count on the other. A mismatch means the forwarding path is dropping in software.
• Core layout. A pair used for forwarding should be on the same NUMA node as the NIC. Cross-socket forwarding shows up as a throughput ceiling that no amount of tuning recovers.

Common Setup Failures

• "No probed ethernet devices" — the interface is still bound to the kernel driver, or the PCI address in -w/-a is wrong.
• Hugepage allocation error — hugepages were not reserved at boot, or the mount point passed to --huge-dir is not where they were allocated.
• Forwarding starts but nothing transmits — in io mode there is no peer sending traffic. Switch to txonly with --tx-first, or connect a real peer.

Related on this site: DPDK Hugepages and NUMA Memory Tuning fundamentals including hugepage and NUMA tuning, SR-IOV, Multus and DPDK: CNF Networking on Kubernetes for DPDK inside Kubernetes, and Linux IRQ Affinity, RSS, RPS and XPS Tuning for the kernel-driver equivalent of the core-pinning work done here.

原文链接：https://doc.dpdk.org/guides/testpmd_app_ug/run_app.html