Wireblast pushes 135M packets a second from one Go binary

A 14 MB static Go binary that pushes 135 million packets per second out of a 100G Mellanox NIC would have sounded like a joke five years ago. That's what Wireblast, a new open-source traffic generator from Border0 founder Andree Toonk, claims to do — and the interesting part isn't the tool itself. It's what the tool proves: for a whole class of network testing, the DPDK tax is no longer worth paying.

The iperf3 ceiling is real, and it's the kernel

Every network engineer has done this dance: you build a firewall, a load balancer, or an eBPF dataplane, and you want to know how many packets per second it survives. You reach for iperf3, watch it happily saturate the link with 1,500-byte frames, and learn nothing — because your device dies on packet rate, not bandwidth, and iperf3's traffic never leaves the kernel's socket path. At 100G, line rate for 64-byte frames is 148.8 Mpps. The Linux network stack, even tuned, gives up two orders of magnitude below that per core.

The traditional answer was to graduate to serious tooling: Cisco's TRex, pktgen-dpdk, MoonGen, or a five-figure Ixia chassis. All of the software options ride on DPDK, which means hugepages, unbinding the NIC from its kernel driver, dedicated cores, and a setup ritual long enough that most teams do it once, on one lab box, and never touch it again. The capability existed; the friction kept it away from everyday work.

AF_XDP quietly closed the gap

AF_XDP — the socket family that landed in Linux 4.18 back in 2018 — was supposed to change that: kernel-bypass speeds through a shared memory region (UMEM) and lock-free rings, while the NIC stays a normal interface that ip addr still understands. In practice, adoption stayed niche because the raw API is gnarly. You're hand-managing four rings, buffer recycling, and per-driver zero-copy quirks. Most of the ecosystem's attention went to load balancers (Facebook's Katran) and CNI dataplanes, not test tooling.

Wireblast packages that machinery behind an iperf-shaped interface. One command, no config:

sudo wireblast -i eth1 --dst-ip 192.0.2.10 --packet-size 512 --pps 1M -d 30s

There's an interactive wizard if you don't remember the flags, a --no-tui mode for CI scripts, and modes for fixed-size UDP, TCP SYN floods, IMIX mixes, raw Ethernet, and PCAP replay. It can fan traffic across thousands of distinct flows by varying source ports — which is exactly what you need to exercise RSS queue distribution, ECMP hashing, or a load balancer's connection table, and exactly what iperf3 can't do.

Toonk's own benchmarks: 14.88 Mpps — full line rate — on a 10G Intel NIC with 64-byte frames, and on 100G ConnectX hardware, 135 Mpps at the smallest frame size, with 512-byte and 1,518-byte frames both saturating the link at ~98 Gbit/s. Those numbers are author-reported and the project is days old, so treat them as a claim, not a datasheet. But they're consistent with published AF_XDP zero-copy results, and the underlying math checks out. The credible part is the pedigree: Toonk has spent two years publicly documenting the path from net.Dial (~100 Kpps) through syscall batching to AF_XDP in Go, and the socket layer here is a standalone library, go-afxdp, you can build your own tools on.

That Go detail deserves a beat. The folk wisdom says GC languages don't do line-rate packet work — that's Rust and C territory. Wireblast is a counterexample with an asterisk: AF_XDP moves the hot path into shared memory rings, so Go is orchestrating buffers rather than copying packets, and the garbage collector never sees the data plane. It's less "Go got fast" and more "the kernel API got good enough that language overhead stopped mattering."

Where it fits in your toolbox

The practical pitch: keep iperf3 for host-to-host throughput sanity checks, and add Wireblast where packet rate is the question. Concretely, that's stress-testing a firewall's conntrack table with 10,000 flows of SYNs, validating that RSS actually spreads load across your queues, finding the pps cliff on a VPP or eBPF forwarding path before production does, or wiring a regression gate into CI — go install github.com/atoonk/wireblast/cmd/wireblast@latest on a runner with a spare NIC, parse the plain-text output, fail the build if forwarding drops below target.

The caveats matter. Hitting these numbers requires a NIC driver with AF_XDP zero-copy support — Intel and Mellanox are solid; on anything else you fall back to generic XDP and the numbers crater. Cloud is trickier: go-afxdp handles AWS ENA's buffer-alignment quirks, but virtualized NICs won't give you 100G-class rates. And Wireblast deliberately punts on the hard 20%: no latency or jitter measurement, no hardware timestamping, and its "TCP" is stateless SYN generation, not real sessions. RFC 2544-grade characterization still belongs to TRex and the commercial chassis vendors. Toonk says as much — this "is not trying to replace an Ixia."

The judgement

That restraint is why this is the right product and not another half-finished pktgen clone. The gap between "iperf3 said the link is fine" and "we racked a TRex box" is enormous, and most dataplane bugs live in it. A zero-setup tool that covers the easy 80% at line rate will get used weekly; a comprehensive one that takes an afternoon to configure gets used never.

The bigger signal is for anyone still defaulting to DPDK for new tooling. When a single Go binary with no kernel modules, no hugepages, and no NIC exorcism gets within a rounding error of line rate, the operational case for kernel bypass frameworks shrinks to the workloads that genuinely need their last few percent and their mature ecosystems. AF_XDP spent eight years as the future of Linux fast networking. Tools like this are what it looks like when the future ships.