baidu/dperf: a DPDK-based packet generator for L4 load testing

What dperf is for, and who ends up using it

dperf is a network traffic generator and load testing tool built on DPDK. The README lists four use cases: load and stability testing for Layer 4 load balancers and gateways, network performance benchmarking for cloud servers, evaluation of NIC and CPU packet processing capability, and acting as a high-performance HTTP server or client in a test setup. That list describes a fairly narrow audience. The tool is for people who own the hardware under test and can afford to take a second machine out of production to drive traffic at it.

The project comes from Baidu. The README credits Jianzhang Peng, who it says worked on high-performance L4 load balancer systems at Baidu and continues to maintain dperf as an open source contributor. That origin explains the shape of the tool: it is aimed at the same problem its author worked on, which is proving that a load balancer or gateway holds up under connection rates and packet rates that ordinary tools cannot reach. A team benchmarking a cloud instance or validating a new NIC will find the same feature set useful, but the design assumptions come from the load balancer world.

If your testing need is functional rather than volumetric, dperf is the wrong instrument. It does not try to be a scripting harness with assertions and scenario logic. It generates traffic at a configured rate and reports counters. The README presents it as a traffic generator and load testing tool, and the statistics output is the primary feedback channel.

How dperf generates traffic: DPDK, per-core sockets and a config file

The mechanism is visible in the Makefile. The application is assembled from source files with clear responsibilities: src/socket.c, src/tcp.c, src/http.c, src/arp.c, src/icmp.c, src/ip.c, src/eth.c, src/server.c, src/client.c, src/port.c, src/config.c, src/config_keyword.c, src/net_stats.c, src/tick.c. There is a src/kni.c for older DPDK releases and src/virtio-user.c for DPDK 20.11 and later. This is a userspace TCP/IP stack, not a wrapper around the kernel socket API. dperf sends and receives frames directly through DPDK poll mode drivers.

Because the stack lives in userspace, the tool keeps its own socket table. The statistics block in the README shows counters named skOpen, skClose, skCon and skErr alongside synRx, synTx, finRx, finTx, ackRt and pushRt. Those names tell you the data flow: dperf opens and closes connections itself, tracks how many are concurrently open, and counts TCP state transitions as packets arrive and leave. The httpGet, http2XX and httpErr counters sit on top of that, so HTTP requests are parsed inside the same userspace path. The Makefile passes -DHTTP_PARSE when compiling, which matches the presence of src/http.c and src/http_parse.c.

Configuration is read from a file through src/config.c and src/config_keyword.c. The README does not reproduce the keyword list, and points to https://dperf.org/ for documentation. That is the first place to look before writing a test, because the repository README alone does not enumerate the accepted keys.

Output is a per-second line of counters. The README gives this example of the format:

seconds 22                 cpuUsage 52
pktRx   3,001,058          pktTx    3,001,025          bitsRx   2,272,799,040      bitsTx  1,920,657,600      dropTx  0
synRx   1,000,345          synTx    1,000,330          finRx    1,000,350          finTx   1,000,350          rstRx   0          rstTx 0
skOpen  1,000,330          skClose  1,000,363          skCon    230                skErr   0
httpGet 1,000,345          http2XX  1,000,350          httpErr  0
ierrors 0                  oerrors  0                  imissed  0

The dropTx, tcpDrop, skErr, ierrors, oerrors and imissed counters are the ones to watch. A test that reports the traffic rate you asked for but a rising imissed count is not measuring what you think it is.

Building dperf against libdpdk and running a first test

The Makefile supports two build paths. With RTE_SDK defined it uses the older DPDK build system and expects RTE_TARGET, defaulting to x86_64-native-linuxapp-gcc. Without RTE_SDK it uses pkg-config and fails early if DPDK is not installed. The error message is explicit:

make
# $(error "no installation of DPDK found") if pkg-config cannot find libdpdk

So the practical prerequisite is a DPDK installation that pkg-config can see. On a system where DPDK is installed under a non-default prefix, point PKG_CONFIG_PATH at its .pc directory before running make. The Makefile also links -lrte_net_bond and -lrte_bus_vdev, and passes -DALLOW_EXPERIMENTAL_API, so the DPDK build you use must expose those libraries. A minimal DPDK build that omits the bond or vdev drivers will fail at link time rather than at compile time.

The repository layout is flat: Makefile, src/, test/, CHANGELOG.md, CONTRIBUTING.md, LICENSE, README.md. There is no configure script and no package manifest for a distribution. Build it from the checkout:

make

Before the first run, DPDK needs hugepages and a NIC bound to a poll mode driver. Those steps belong to DPDK, not to dperf, and the dperf README does not walk through them. The DPDK documentation for your release covers them. Once the environment is ready, dperf reads a configuration file, and the keyword list lives at https://dperf.org/ rather than in the repository README. A first test should therefore start small: one client core, one server core, a modest connection rate, and a short duration, then read the per-second output to confirm that pktRx and pktTx are close and that dropTx, tcpDrop and imissed stay at zero. If those counters move, fix the environment before scaling the test up.

The README's own numbers give a sense of what to expect from scaling. With one client core and one server core it reports 4 million HTTP CPS at 74 percent client CPU and 71 percent server CPU. At 16 cores on each side it reports 64 million CPS at 70 and 68 percent. The throughput table reports 98.3 Gbps in each direction with one core per side on a dual-port 100GbE NIC, and 196.7 Gbps with two. Those figures come from a specific machine: two Intel Xeon Gold 5418Y CPUs, 256 GB of memory, two Intel E810-C dual-port 100GbE NICs, Linux 5.10.0. Treat them as a description of the test platform, not as a promise for yours.

The hardware bill: cores, memory and a NIC you give up

The concurrent connection table is the clearest limitation in the README. One client core and one server core hold 1 billion connections using 60 GB of memory at 48 percent CPU. Two cores per side reach 2 billion at 120 GB. Four cores per side reach 4 billion at 240 GB. The memory scales linearly with the connection count, roughly 60 GB per billion connections per side. That is not a tuning problem; it is the cost of keeping a socket entry for every open connection in userspace. A machine with 128 GB of RAM cannot run the 4-billion-connection test at all.

The packet rate table shows the other constraint. One core reaches 16.8 Mpps at 99 percent CPU. Six cores reach 105.2 Mpps, twelve reach 204.6 Mpps, both at 99 percent CPU. Once a core is at 99 percent, adding work to it does nothing; the test scales only by adding cores. That means the client machine needs enough cores to drive the rate you want, and those cores are unavailable for anything else during the run.

There is also the DPDK precondition itself. dperf takes over NICs through poll mode drivers, so the ports it uses are not available to the host network stack while dperf runs. On a machine with a single management NIC, binding that NIC to DPDK cuts off SSH access. The usual arrangement is a separate port for management or a serial console. The README does not discuss this operational cost, and it is the detail that most often surprises people trying dperf for the first time.

Finally, the README does not document rollback, and it does not describe how to return a bound NIC to the kernel. That procedure belongs to DPDK and to the driver tooling on your distribution. Plan for it before you bind the first port.

Where dperf sits next to other load testing tools

The obvious alternative for many teams is a kernel-socket load generator. Tools in that family open real sockets through the operating system and drive traffic from ordinary processes. They install with a package manager, run without root on a dedicated NIC, and coexist with everything else on the machine. Their ceiling is the kernel network stack: connection setup and teardown pass through the same path as any other application, and the cost per connection is far higher than a userspace stack that keeps its own socket table.

That difference decides the choice. If you need to prove that an L4 load balancer sustains millions of new connections per second, a kernel-socket tool will saturate its own host before it saturates the device under test, and the result tells you about the generator rather than the target. dperf exists for that gap. If you need a scripted scenario with conditional logic, response validation and a report, dperf's configuration-file model and counter output are a poorer fit, and the kernel-socket tool is the better choice despite the lower ceiling.

There is a middle option worth naming: hardware test equipment. A dedicated appliance generates traffic without consuming a general-purpose server and typically comes with vendor support. It also costs far more, and it is less convenient to script into a CI pipeline. dperf occupies the space between the two: DPDK performance on hardware you already own, with the operational burden of DPDK attached.

One more comparison is internal to dperf. The README notes that it can act as a high-performance HTTP server or client. That makes it usable for testing another dperf instance, or for testing a real server's HTTP handling at rates a normal client cannot reach. It is not a substitute for a functional HTTP test suite. The http2XX and httpErr counters tell you how many responses fell into broad classes; they do not check response bodies.

Release cadence, licence and the cost of staying current

The repository is not archived, and the last push was on 2026-08-07. The most recent release listed is v1.9.0, dated 2025-07-23, following v1.8.0 on 2024-12-12 and v1.7.0 on 2024-06-05. That is roughly one release every six to seven months across the three most recent tags. The CHANGELOG.md at the repository root is where the differences between them are recorded; the README does not summarise release-to-release changes.

Upgrade cost depends on the DPDK version you build against, not on dperf alone. The Makefile has a branch for DPDK 17.11, 18.11 and 19.11 that uses RTE_SDK and compiles src/kni.c, and a branch for DPDK 20.11 and later that uses pkg-config and compiles src/virtio-user.c instead. The comment in the Makefile names DPDK 20.11 as the boundary. Moving to a newer DPDK means moving to the pkg-config path and losing the KNI code path; staying on an older DPDK means keeping RTE_SDK set. Either way, a DPDK upgrade on the test host is a larger change than a dperf upgrade, because it can require rebinding NICs and rebuilding the poll mode drivers.

On licensing, dperf is under the Apache License 2.0, and the LICENSE file is at the repository root. That is a permissive licence, but it says nothing about DPDK, which is distributed under its own terms and is a separate dependency you install yourself. If you redistribute a product that links DPDK, check DPDK's licence separately. Nothing here is legal advice; read both licences if redistribution is on the table.

The README also notes a patent: CN114205274B, titled "Testing Method and Apparatus for Network Devices", inventor Jianzhang Peng, issued 2024-06-11. The README states the patent exists but does not describe what it covers or how it relates to using the software. That is worth a look if you plan to build a commercial product around the same testing method.

Editorial conclusion

Adopt dperf if you have a spare x86 server, an Intel or compatible NIC you can detach from the kernel, and a test target that deserves tens of millions of connections per second. Do not adopt it if you need a tool that runs as an ordinary userspace process on a shared machine, or if your team cannot give up a NIC to DPDK. Before committing, verify that your DPDK version satisfies the pkg-config check in the Makefile, confirm the NIC is supported by the DPDK release you install, and read the configuration keyword list because the README does not document every option it accepts.

Frequently asked questions

Official sources

1. baidu/dperf on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases