HN Debrief

Wireblast a 100 Gbps packet generator in Go using AF_XDP

  • Infrastructure
  • Networking
  • Open Source
  • Developer Tools

The post points to Wireblast, an open source packet generator in Go that uses AF_XDP to drive packets at 100 Gbps. AF_XDP is a Linux path for moving packets between user space and the network card with far less kernel overhead than the normal socket stack, which is why this is notable in a garbage collected language instead of the usual C plus DPDK setup. The practical takeaway from the comments is that the interesting part is not Go itself. It is that AF_XDP has matured into a much simpler way to build high-speed networking tools without the operational weight people associate with DPDK. Comments also sharpened the hardware story. One concern was that AF_XDP needs special NIC support, which would limit who can use it. The pushback was that for the kind of 100 GbE hardware this tool targets, Linux driver support is common enough that this is rarely the real blocker. And even without full driver support, generic AF_XDP can run at the traffic control layer with lower performance, which makes it usable for development setups like veth-based tests. The overall tone was upbeat. People saw this as a sign that high-rate packet generation is getting easier and more accessible.

If you build or test high-performance networking systems, AF_XDP now looks like the default place to start before reaching for DPDK. Also check whether your target environment can use driver-backed AF_XDP or only generic mode, because that decides how much of the headline performance you can actually expect.

Discussion mood

Positive and curious. People liked seeing a simpler path to high-speed packet generation, especially one in Go, and the main discussion was about where AF_XDP fits relative to DPDK and how much NIC support limits real-world use.

Key insights

  1. 01

    AF_XDP avoids per-packet skbuff overhead

    Writing through AF_XDP means user space can feed the NIC through DMA-friendly buffers instead of paying for a full sk_buff allocation on every transmitted packet. That is the key reason it is not interchangeable with TC BPF for this use case. It changes the bottleneck from kernel bookkeeping to how efficiently you manage rings and memory.

    If you are evaluating packet I/O options, compare memory movement and packet metadata costs first, not just whether both paths "bypass the kernel." TC BPF may be good enough for control logic, but line-rate traffic generation depends on avoiding per-packet allocation work.

      Attribution:
    • tptacek #1
  2. 02

    Generic AF_XDP gives you a fallback path

    Running AF_XDP in generic mode at the traffic control layer means the model is still usable even when you do not have full zero-copy driver support. That makes Wireblast more than a narrow benchmark toy, because the same programming approach can be exercised in virtual Ethernet setups and lower-end environments before moving to tuned hardware.

    You can prototype and validate AF_XDP-based tooling in ordinary Linux testbeds, then reserve specialized NIC tuning for the last mile. That lowers adoption risk for teams deciding whether to build around this interface.

      Attribution:
    • bgpdude #1 #2
  3. 03

    100 GbE NIC support is often a solved problem

    For the hardware class implied by a 100 Gbps packet generator, lack of AF_XDP-capable Linux drivers is probably less limiting than it sounds. The useful framing is that this tool is aimed at datacenter-grade cards, and those cards generally already have the kernel support needed to make AF_XDP practical.

    Do not dismiss AF_XDP on the assumption that it is exotic hardware territory. If your deployment already involves 100 GbE adapters, validate the specific driver path you need, but expect support to be present more often than not.

      Attribution:
    • Palomides #1
  4. 04

    DPDK now carries a justification burden

    The strongest reaction was not "nice Go project" but relief at the idea of avoiding DPDK entirely. That says something about the market. XDP-era Linux networking is now good enough that new tools can start from kernel-supported packet paths and only defend a move to DPDK when they truly need its ecosystem or edge-case performance.

    For new packet processing projects, make DPDK the exception you prove, not the baseline you assume. Teams can save integration and maintenance effort by exhausting AF_XDP and XDP options first.

      Attribution:
    • barryvand #1
    • tptacek #1

Against the grain

  1. 01

    NIC dependence still narrows the audience

    Requiring AF_XDP support in the NIC path still makes this less universal than a tool built on more ordinary kernel mechanisms. That concern matters if you want something every developer can run locally, not just operators with the right server hardware.

    If broad internal adoption matters, plan for a degraded mode or alternative backend from day one. Otherwise your fastest path may only be usable by the small slice of the team with matching lab gear.

      Attribution:
    • spaceywilly #1

In plain english

100 GbE ↩
100 Gigabit Ethernet, a network link speed of 100 billion bits per second.
AF_XDP ↩
A Linux socket interface built on eXpress Data Path that lets user-space programs send and receive packets with very low overhead.
DMA ↩
Direct Memory Access, a hardware mechanism that lets devices read and write system memory without constant CPU involvement.
DPDK ↩
Data Plane Development Kit, a set of user-space libraries and drivers for very high-speed packet processing.
NIC ↩
Network interface card, the hardware adapter that connects a machine to a network.
sk_buff ↩
The Linux kernel data structure used to represent a network packet as it moves through the normal networking stack.
TC BPF ↩
Traffic Control Berkeley Packet Filter, a way to run packet-processing programs in Linux at the traffic control layer.
veth ↩
Virtual Ethernet, a paired virtual network interface often used to connect containers, namespaces, or test environments inside Linux.
XDP ↩
eXpress Data Path, a Linux packet processing framework that runs very early in the network stack for high performance.

Reference links

Article and demo