xdp-bench(8)

📦
version 1.6.3 · 13 versions
, in arch rolling, ubuntu stonking

✨ NAME ✨

xdp-bench — a simple XDP benchmarking tool 💖

🦋 SYNOPSIS 🦋

xdp-bench is a benchmarking utility for exercising the different operation modes of XDP, bestie. It's meant to be a simple little program that shows off all the various operating modes — and those include dropping packets, hairpin forwarding (that's the one where you return XDP_TX), and redirection using the various in-kernel packet redirection facilities. iconic behaviour tbh 💅

The drop and TX modes have a bunch of options that control whether packet data gets touched (read or written) before it's dropped or transmitted. The redirection modes support using the simple ifindex-based bpf_redirect helper, the bpf_redirect_map helper using a cpumap as its target, bpf_redirect_map using a devmap as its target, and the devmap's broadcast mode, which lets you redirect to multiple devices at once. so many flavours fr fr 🍓

There is more information on the meaning of the output in both default (terse) and extended output mode, in the Output Format Description section below. 👑

🌸 Running xdp-bench 🌸

The syntax for running xdp-bench is:

Usage: xdp-bench COMMAND [options]

COMMAND can be one of:
       drop           - Drop all packets on an interface
       pass           - Pass all packets to the network stack
       tx             - Transmit packets back out on an interface (hairpin forwarding)
       redirect       - XDP redirect using the bpf_redirect() helper
       redirect-cpu   - XDP CPU redirect using BPF_MAP_TYPE_CPUMAP
       redirect-map   - XDP redirect using BPF_MAP_TYPE_DEVMAP
       redirect-multi - XDP multi-redirect using BPF_MAP_TYPE_DEVMAP and the BPF_F_BROADCAST flag
       xsk-drop       - AF_XDP socket-based drop
       xsk-tx         - AF_XDP socket-based hairpin forwarding

Each command, and its options, are explained below. Or, like, if you're impatient (valid ✨), just run xdp-bench COMMAND --help to see the options for each command. 🫶

💀 The DROP command 💀

In this mode, xdp-bench installs an XDP program on an interface that literally just drops all packets. There are options to control what to do with the packet before dropping it (touch the packet data or not), plus which statistics to gather. This is the basic benchmark for the baseline (best-case) performance of XDP on an interface. the vibe check for your NIC basically 💅

The syntax for the drop command is:

xdp-bench drop [options] <ifname>

Where <ifname> is the name of the interface the XDP program should be installed on.

The supported options are:

-p, --packet-operation <ACTION>

Specify which operation should be taken on the packet before dropping it. The following actions are available:

  • no-touch — Drop the packet without touching the packet data
  • read-data — Read a field in the packet header before dropping
  • parse-ip — Parse the IP header field before dropping
  • swap-macs — Swap the source and destination MAC addresses before dropping

Whether to touch the packet before dropping it can have a significant performance impact, because doing so requires bringing packet data into the CPU cache (and flushing it back out if you're writing). 😭

The default for this option is no-touch.

-l, --load-mode <MODE>

Specify which mechanism xdp-bench should use to load (and store) the packet data. The following modes are available:

  • dpa — Use traditional Direct Packet Access from the XDP program
  • load-bytes — Use the xdp_load_bytes() and xdp_store_bytes() helper functions

This can be used to benchmark the various packet access modes supported by the kernel. 🧚

The default for this option is dpa.

-r, --rxq-stats

If set, the XDP program will also gather statistics on which receive queue index each packet was received on. This is displayed in the extended output mode along with per-CPU data (which, depending on the hardware configuration, may or may not be equivalent). 👑

-i, --interval <SECONDS>

Set the polling interval for collecting all statistics and displaying them to the output. The unit of interval is in seconds. ⏱️

-e, --extended

Start xdp-bench in "extended" output mode. If not set, xdp-bench will start in "terse" mode. The output mode can be switched by hitting C-$ while the program is running. See also the Output Format Description section below. ✨

-m, --mode

Selects the XDP program mode (native or skb). Note that native XDP mode is the default, and loading the redirect program in skb manner is neither performant, nor recommended. However, this option is useful if the interface driver lacks native XDP support, or when you're simply testing the tool. 🙈

-v, --verbose

Enable verbose logging. Supply it twice to enable verbose logging from the underlying libxdp and libbpf libraries. 🔥

--version

Show the application version and exit.

-h, --help

Display a summary of the available options.

🎀 The PASS command 🎀

In this mode, xdp-bench installs an XDP program on an interface that passes all packets to the network stack after processing them (it returns XDP_PASS). There are options to control what to do with the packet before passing it (touch the packet data or not), plus which statistics to gather. This is the basic benchmark for the overhead of installing an XDP program on an interface while still running the regular network stack. lowkey the "excuse me, just passing through" mode 💅

The syntax for the pass command is:

xdp-bench pass [options] <ifname>

Where <ifname> is the name of the interface the XDP program should be installed on.

The supported options are:

-p, --packet-operation <ACTION>

Specify which operation should be taken on the packet before passing it. The following actions are available:

  • no-touch — Pass the packet without touching the packet data
  • read-data — Read a field in the packet header before passing
  • parse-ip — Parse the IP header field before passing
  • swap-macs — Swap the source and destination MAC addresses before passing

The default for this option is no-touch.

-l, --load-mode <MODE>

Specify which mechanism xdp-bench should use to load (and store) the packet data. The following modes are available:

  • dpa — Use traditional Direct Packet Access from the XDP program
  • load-bytes — Use the xdp_load_bytes() and xdp_store_bytes() helper functions

This can be used to benchmark the various packet access modes supported by the kernel. 🧚

The default for this option is dpa.

-r, --rxq-stats

If set, the XDP program will also gather statistics on which receive queue index each packet was received on. This is displayed in the extended output mode along with per-CPU data (which, depending on the hardware configuration, may or may not be equivalent). 👑

-i, --interval <SECONDS>

Set the polling interval for collecting all statistics and displaying them to the output. The unit of interval is in seconds. ⏱️

-e, --extended

Start xdp-bench in "extended" output mode. If not set, xdp-bench will start in "terse" mode. The output mode can be switched by hitting C-$ while the program is running. See also the Output Format Description section below. ✨

-m, --mode

Selects the XDP program mode (native or skb). Note that native XDP mode is the default, and loading the redirect program in skb manner is neither performant, nor recommended. However, this option is useful if the interface driver lacks native XDP support, or when you're simply testing the tool. 🙈

-v, --verbose

Enable verbose logging. Supply it twice to enable verbose logging from the underlying libxdp and libbpf libraries. 🔥

--version

Show the application version and exit.

-h, --help

Display a summary of the available options.

🌈 The TX command 🌈

In this mode, xdp-bench installs an XDP program on an interface that performs so-called "hairpin forwarding" — which means every single packet is transmitted back out the same interface (using the XDP_TX return code). 💫 There are options to control what to do with the packet before transmitting it (touch the packet data or not), plus which statistics to gather.

The syntax for the tx command is:

xdp-bench tx [options] <ifname>

Where <ifname> is the name of the interface the XDP program should be installed on.

The supported options are:

-p, --packet-operation <ACTION>

Specify which operation should be taken on the packet before transmitting it. The following actions are available:

  • no-touch — Transmit the packet without touching the packet data
  • read-data — Read a field in the packet header before transmitting
  • parse-ip — Parse the IP header field before transmitting
  • swap-macs — Swap the source and destination MAC addresses before transmitting

To allow the packet to be successfully transmitted back to the sender, the MAC addresses have to be swapped, so that the source MAC matches the network device. However, there is a performance overhead in doing the swapping, so this option allows this function to be turned off. 🫶

The default for this option is swap-macs.

-l, --load-mode <MODE>

Specify which mechanism xdp-bench should use to load (and store) the packet data. The following modes are available:

  • dpa — Use traditional Direct Packet Access from the XDP program
  • load-bytes — Use the xdp_load_bytes() and xdp_store_bytes() helper functions

This can be used to benchmark the various packet access modes supported by the kernel. 🧚

The default for this option is dpa.

-r, --rxq-stats

If set, the XDP program will also gather statistics on which receive queue index each packet was received on. This is displayed in the extended output mode along with per-CPU data (which, depending on the hardware configuration, may or may not be equivalent). 👑

-i, --interval <SECONDS>

Set the polling interval for collecting all statistics and displaying them to the output. The unit of interval is in seconds. ⏱️

-e, --extended

Start xdp-bench in "extended" output mode. If not set, xdp-bench will start in "terse" mode. The output mode can be switched by hitting C-$ while the program is running. See also the Output Format Description section below. ✨

-m, --mode

Selects the XDP program mode (native or skb). Note that native XDP mode is the default, and loading the redirect program in skb manner is neither performant, nor recommended. However, this option is useful if the interface driver lacks native XDP support, or when you're simply testing the tool. 🙈

-v, --verbose

Enable verbose logging. Supply it twice to enable verbose logging from the underlying libxdp and libbpf libraries. 🔥

--version

Show the application version and exit.

-h, --help

Display a summary of the available options.

🎀 The REDIRECT command 🎀

okay bestie, this one is the classic. In this mode, xdp-bench sets up packet redirection between the two interfaces you hand it on the command line, using the bpf_redirect BPF helper — and that helper fires on packet reception on the ingress interface. cute, efficient, iconic 💅

The syntax for the redirect command is:

xdp-bench redirect [options] <ifname_in> <ifname_out>

Where <ifname_in> is the name of the input interface from where packets will be redirect to the output interface <ifname_out>. (yes, packets go in one door and out the other, main character energy fr fr 🚪➡️🚪)

The supported options are:

  • -l, --load-mode <MODE> — tell xdp-bench which mechanism it should use to load (and store) the packet data. The following modes are available:
    • dpa — Use traditional Direct Packet Access from the XDP program
    • load-bytes — Use the xdp_load_bytes() and xdp_store_bytes() helper functions

This can be used to benchmark the various packet access modes supported by the kernel. The default for this option is dpa.

  • -i, --interval <SECONDS> — set the polling interval for collecting all statistics and displaying them to the output. The unit of interval is in seconds. ⏱️
  • -s, --stats — enable statistics for successful redirection. Heads up though: this option comes with a per packet tracing overhead, for recording all successful redirections. so it's giving "we're watching everything and it costs us" 😭
  • -e, --extended — start xdp-bench in "extended" output mode. If not set, xdp-bench will start in "terse" mode. The output mode can be switched by hitting C-$ while the program is running. See also the Output Format Description section below. ✨
  • -m, --mode — selects the XDP program mode (native or skb). Note that native XDP mode is the default, and loading the redirect program in skb manner is neither performant, nor recommended. However, this option is useful if the interface driver lacks native XDP support, or when simply testing the tool.
  • -v, --verbose — enable verbose logging. Supply twice to enable verbose logging from the underlying libxdp and libbpf libraries. 🗣️
  • --version — show the application version and exit.
  • -h, --help — display a summary of the available options

🧠 The REDIRECT-CPU command 🧠

okay this one is lowkey my fave. In this mode, xdp-bench sets up packet redirection using the bpf_redirect_map BPF helper triggered on packet reception on the ingress interface, using a cpumap as its target. So basically this tool can redirect packets on an interface from one CPU to another 🧚 And on top of that, it then supports redirecting the packet to another output device when it is processed on the target CPU. multitasking queen behavior 👑

The syntax for the redirect-cpu command is:

xdp-bench redirect-cpu [options] <ifname> -c 0 ... -c N

Where <ifname> is the name of the input interface from where packets will be redirect to the target CPU list specified using -c.

The supported options are:

  • -c, --cpu <CPU> — specify a possible target CPU index. This option must be passed at least once, and can be passed multiple times to specify a list of CPUs. Which CPU is chosen for a given packet depends on the value of the --program-mode option, described below.
  • -p, --program-mode <MODE> — specify a program that embeds a predefined policy deciding how packets are redirected to different CPUs. The following options are available:
    • no-touch — Redirect without touching packet data
    • touch — Read packet data before redirecting
    • round-robin — Cycle between target CPUs in a round-robin fashion (for each packet)
    • l4-proto — Choose the target CPU based on the layer-4 protocol of packet
    • l4-filter — Like l4-proto, but drop UDP packets with destination port 9 (used by pktgen)
    • l4-hash — Use source and destination IP hashing to pick target CPU
    • l4-sport — Use modulo of source port to pick target CPU
    • l4-dport — Use modulo of destination port to pick target CPU

The no-touch and touch modes always redirect packets to the same CPU (the first value supplied to --cpu). The round-robin and l4-hash modes distribute packets between all the CPUs supplied as --cpu arguments, while l4-proto and l4-filter send TCP and unrecognised packets to CPU index 0, UDP packets to CPU index 1 and ICMP packets to CPU index 2 (where the index refers to the order the actual CPUs are given on the command line).

The default for this option is l4-hash.

  • -r --remote-action <ACTION> — if this option is set, a separate program is installed into the cpumap, which will be invoked on the remote CPU after the packet is processed there. The action can be either drop or pass, which will drop the packet or pass it to the regular networking stack, respectively. Or it can be redirect, which will cause the packet to be redirected to another interface and transmitted out that interface on the remote CPU. If this option is set to redirect the target device must be specified using --redirect-device.

The default for this option is disabled.

  • -r, --redirect-device <IFNAME> — specify the device to redirect the packet to when it is received on the target CPU. Note that this option can only be specified with --remote-action redirect.
ngl bestie, yes — both of these are written as -r in the page. I don't make the rules, I just report them 💀
  • -q, --qsize <PACKETS> — set the queue size for the per-CPU cpumap ring buffer used for redirecting packets from multiple CPUs to one CPU. The default value is 2048 packets.
  • -x, --stress-mode — stress the cpumap implementation by deallocating and reallocating the cpumap ring buffer on each polling interval. it's giving chaos for science 🫠🔥
  • -i, --interval <SECONDS> — set the polling interval for collecting all statistics and displaying them to the output. The unit of interval is in seconds.
  • -s, --stats — enable statistics for successful redirection. This option comes with a per packet tracing overhead, for recording all successful redirections.
  • -e, --extended — start xdp-bench in "extended" output mode. If not set, xdp-bench will start in "terse" mode. The output mode can be switched by hitting C-$ while the program is running. See also the Output Format Description section below.
  • -m, --mode — selects the XDP program mode (native or skb). Note that native XDP mode is the default, and loading the redirect program in skb manner is neither performant, nor recommended. However, this option is useful if the interface driver lacks native XDP support, or when simply testing the tool.
  • -v, --verbose — enable verbose logging. Supply twice to enable verbose logging from the underlying libxdp and libbpf libraries.
  • --version — show the application version and exit.
  • -h, --help — display a summary of the available options

🗺️ The REDIRECT-MAP command 🗺️

In this mode, xdp-bench sets up packet redirection between two interfaces supplied on the command line using the bpf_redirect_map() BPF helper triggered on packet reception on the ingress interface, using a devmap as its target. it's the same idea as before but the map is a devmap this time, obsessed with the range honestly 💖

The syntax for the redirect-map command is:

xdp-bench redirect-map [options] <ifname_in> <ifname_out>

Where <ifname_in> is the name of the input interface from where packets will be redirect to the output interface <ifname_out>.

The supported options are:

  • -X, --load-egress — load a program in the devmap entry used for redirection, so that it is invoked after the packet is redirected to the target device, before it is transmitted out of the output interface. The program can be selected via the egress-mode option.
  • -A, --egress-mode <MODE> — set egress program to load:
    • forward — Update the packet data so its source MAC address matches the one of the destination interface.
    • drop — Drop packet.

The default for this option is forward.

  • -i, --interval <SECONDS> — set the polling interval for collecting all statistics and displaying them to the output. The unit of interval is in seconds.
  • -s, --stats — enable statistics for successful redirection. This option comes with a per packet tracing overhead, for recording all successful redirections.
  • -e, --extended — start xdp-bench in "extended" output mode. If not set, xdp-bench will start in "terse" mode. The output mode can be switched by hitting C-$ while the program is running. See also the Output Format Description section below.
  • -m, --mode — selects the XDP program mode (native or skb). Note that native XDP mode is the default, and loading the redirect program in skb manner is neither performant, nor recommended. However, this option is useful if the interface driver lacks native XDP support, or when simply testing the tool.
  • -v, --verbose — enable verbose logging. Supply twice to enable verbose logging from the underlying libxdp and libbpf libraries.
  • --version — show the application version and exit.
  • -h, --help — display a summary of the available options

💫 The REDIRECT-MULTI command 💫

Okay bestie, so this one is the one-to-many version of redirect. xdp-bench sets up packet redirection from one input interface out to one or more output interfaces, using the bpf_redirect_map BPF helper that fires when a packet shows up on the ingress interface, with a devmap as its target. Then the packet gets broadcast to every single output interface you listed on the command line, using devmap's packet broadcast feature. It's giving group chat blast, but for packets 💅

The syntax for the redirect-multi command is:

xdp-bench redirect-multi [options] <ifname_in> <ifname_out1> ...
<ifname_outN>

Where <ifname_in> is the name of the input interface from where packets will be redirect to one or many output interface(s). Yes, that's the original wording and it's lowkey iconic, so it stays 🫶

The supported options are:

  • -X, --load-egress — Loads a program in the devmap entry used for redirection, so it gets invoked after the packet is redirected to the target device, but before it's transmitted out of the output interface. You pick which program with the egress-mode option. ✨
  • -A, --egress-mode <MODE> — Sets the egress program to load:
    • forward — Update the packet data so its source MAC address matches the one of the destination interface.
    • drop — Drop packet.

The default for this option is forward.

  • -i, --interval <SECONDS> — Sets the polling interval for collecting all statistics and displaying them to the output. The unit of interval is in seconds. ⏱️
  • -s, --stats — Enables statistics for successful redirection. Heads up though: this option comes with a per packet tracing overhead, for recording all successful redirections. Cute stats, small tax 💀
  • -e, --extended — Starts xdp-bench in "extended" output mode. If not set, xdp-bench will start in "terse" mode. You can switch the output mode on the fly by hitting C-$ while the program is running. See also the Output Format Description section below. 👀
  • -m, --mode — Selects the XDP program mode (native or skb). Native XDP mode is the default, and loading the redirect program in skb manner is neither performant, nor recommended. That said, it's useful if the interface driver lacks native XDP support, or when you're simply testing the tool. 🙈
  • -v, --verbose — Enable verbose logging. Supply it twice to enable verbose logging from the underlying libxdp and libbpf libraries. Two -vs, double the yapping 📢
  • --version — Show the application version and exit.
  • -h, --help — Display a summary of the available options

🌸 The XSK-DROP and XSK-TX commands 🌸

In these modes, xdp-bench drops or mirrors incoming packets (like when using the drop or tx commands), but using an AF_XDP socket that passes the packets directly from the XDP hook to userspace. So basically it's the same vibe as drop/tx, except the packets take a little detour up to userspace. These modes are perfect for testing and benchmarking AF_XDP sockets. The two commands differ only in the action taken — the syntax and options are otherwise identical. Twins fr fr 👯

The code for these commands is derived from the xdpsock utility previously part of the kernel sources, and more recently the bpf-examples repository. The xsk-drop command corresponds to the --rxdrop option of xdpsock, and the xsk-tx command corresponds to the --l2fwd option of xdpsock. History lesson, but make it slay 📚✨

The syntax and options for the two commands are identical:

xdp-bench xsk-drop [options] <ifname>

or

xdp-bench xsk-tx [options] <ifname>

The supported options are:

  • -q, --queue <queue> — Select the hardware receive queue to use for the test. The AF_XDP socket is bound to this queue, which means that xdp-bench will process all packets arriving on it. The default is to use queue 0.
  • -i, --interval <seconds> — Set the polling interval for collecting all statistics and displaying them to the output. The default interval is 2 seconds. ⏰
  • -f, --frame-size <size> — Set the size of the memory frames used to receive packets. Incoming packets will always use a memory chunk of this size, regardless of the size of the packet on the wire. The size must be a power of two, unless the --unaligned flag is used. The default is 4096 bytes (which corresponds to the page size on most systems). 📏
  • -d, --duration <seconds> — Set the test duration, in seconds. The default is 0, which means run forever. Bestie said no end time, we go until we feel like it 🫶
  • -b, --batch-size <packets> — Set the batch size for the receive loop. This is the maximum number of packets processed at once each time the loop runs. The default is 64 packets.
  • -I, --irq-string <irq-string> — Enable printing of interrupt statistics for the interrupt number associated with irq-string in /proc/interrupts. The string is used to find a matching IRQ number by simple substring matching. No default (which means no IRQ statistics are printed).
  • -p, --poll — Use the poll() system call to get notifications for new packets, instead of running in a loop constantly checking for new packets. Much chiller, way less spinning 🔄
  • -m, --no-need-wakeup — Don't set the XDP_USE_NEED_WAKEUP flag when binding the AF_XDP socket. The flag is set by default, and causes the kernel driver to occasionally go to sleep and yield the CPU to the userspace application when receiving packets. Letting the driver nap, basically 😴
  • -u, --unaligned — Support receiving unaligned packets, i.e., packets that are not aligned to the beginning of a data frame. When set, xdp-bench will enable huge pages for the userspace memory buffer used to receive packets. Setting this option enables frame sizes that are not a power of two (see the --frame-size option).
  • -M, --shared-umem — Enable shared userspace memory across multiple AF_XDP sockets. When this option is set, xdp-bench will create four sockets that share the same userspace memory buffer, and packets will be sent to each socket in a round-robin fashion. Sharing is caring 💖
  • -x, --extra-stats — Print extra packet statistics at each output interval.
  • -Q, --quiet — Don't print any statistics at each output interval. Silence, but make it intentional 🤫
  • -a, --app-stats — Print additional application-level statistics at each output interval.
  • -B, --busy-poll — Set the SO_PREFER_BUSY_POLL socket option, which enables the application to busy-poll without IRQs ever being enabled on the hardware queue being processed. To make use of this option, the napi_defer_hard_irqs and gro_flush_timeout sysctls should be set for the interface in question. For more information, see https://docs.kernel.org/networking/napi.html#software-irq-coalescing.
  • -F, --frags — Enable XDP fragments. This makes it possible to receive packets that are larger than the system page size, and requires kernel and driver support. ⚠️ kernel and driver support is not optional here, bestie.
  • -C, --copy-mode <mode> — Select the copying mode for the packets. Set to one of auto, copy, or zero-copy. The default is auto, which lets the kernel pick. Using zero-copy requires kernel and driver support, and can only be used when attaching the XDP program in native mode (see --attach-mode). 🚨 remember: zero-copy + skb mode = no.
  • -w, --clock <clock> — Choose the clock that will be used for all timer events in the application. The valid values are MONOTONIC, REALTIME, TAI and BOOTTIME, and the default is MONOTONIC.
  • -W, --policy <policy> — Set the scheduler policy for the application before running. Valid values are SCHED_OTHER and SCHED_FIFO, and the default is SCHED_OTHER.
  • -U, --schpri <priority> — Set the scheduler priority when using SCHED_FIFO. Defaults to 0.
  • -A, --attach-mode <mode> — Set the XDP program attach mode (native or skb). The default is native mode. Note that zero-copy can only be used in native mode. 👑 native mode stays winning.
  • -v, --verbose — Enable verbose logging. Supply twice to enable verbose logging from the underlying libxdp and libbpf libraries.
  • --version — Show the application version and exit.
  • -h, --help — Display a summary of the available options

✨ OUTPUT FORMAT DESCRIPTION ✨

Okay bestie, listen — by default the redirect success stats are off, you have to pass --stats to turn them on. And the terse output mode is the default, but you can unlock the extended output mode with the --extended command line option. 💅

Oh and plot twist: you can switch the mode dynamically at runtime with SIGQUIT (Ctrl+\). Iconic behaviour, honestly. 🌈

🎀 Terse mode

Terse mode shows you at most these fields:

  • rx/s — Number of packets received per second
  • redir/s — Number of packets successfully redirected per second
  • err,drop/s — Aggregated count of errors per second (including dropped packets when not using the drop command)
  • xmit/s — Number of packets transmitted on the output device per second

🔥 Extended output mode

Extended output mode shows you at most these fields (and yeah, it's a lot, it's giving main character energy):

receive

Displays the number of packets received and errors encountered.

Whenever an error or packet drop occurs, details of per CPU error and drop statistics will be expanded inline in terse mode.

  • pkt/s — Packets received per second
  • drop/s — Packets dropped per second
  • error/s — Errors encountered per second

Then:

  • redirect — Displays the number of packets successfully redirected
  • Errors encountered are expanded under redirect_err field
  • Note that passing -s to enable it has a per packet overhead — not free, bestie, it costs you
  • redir/s — Packets redirected successfully per second

redirect_err

Displays the number of packets that failed redirection.

The errno is expanded under this field with per CPU count. The recognized errors are:

  • EINVAL: Invalid redirection
  • ENETDOWN: Device being redirected to is down
  • EMSGSIZE: Packet length too large for device
  • EOPNOTSUPP: Operation not supported
  • ENOSPC: No space in ptr_ring of cpumap kthread

And then:

  • error/s — Packets that failed redirection per second

enqueue to cpu N

Displays the number of packets enqueued to bulk queue of CPU N.

Expands to cpu:FROM->N to display enqueue stats for each CPU enqueuing to CPU N.

Received packets can be associated with the CPU redirect program is enqueuing packets to.

  • pkt/s — Packets enqueued per second from other CPU to CPU N
  • drop/s — Packets dropped when trying to enqueue to CPU N
  • bulk-avg — Average number of packets processed for each event

kthread

Displays the number of packets processed in CPUMAP kthread for each CPU.

Packets consumed from ptr_ring in kthread, and its xdp_stats (after calling CPUMAP bpf prog) are expanded below this. xdp_stats are expanded as a total and then per-CPU to associate it to each CPU's pinned CPUMAP kthread.

  • pkt/s — Packets consumed per second from ptr_ring
  • drop/s — Packets dropped per second in kthread
  • sched — Number of times kthread called schedule()

xdp_stats (also expands to per-CPU counts):

  • pass/s — XDP_PASS count for CPUMAP program execution
  • drop/s — XDP_DROP count for CPUMAP program execution
  • redir/s — XDP_REDIRECT count for CPUMAP program execution

xdp_exception

Displays xdp_exception tracepoint events.

This can occur due to internal driver errors, unrecognized XDP actions and due to explicit user trigger by use of XDP_ABORTED. Each action is expanded below this field with its count:

  • hit/s — Number of times the tracepoint was hit per second

devmap_xmit

Displays devmap_xmit tracepoint events.

This tracepoint is invoked for successful transmissions on output device but these statistics are not available for generic XDP mode, hence they will be omitted from the output when using SKB mode. 🙈

  • xmit/s — Number of packets that were transmitted per second
  • drop/s — Number of packets that failed transmissions per second
  • drv_err/s — Number of internal driver errors per second
  • bulk-avg — Average number of packets processed for each event

🐛 BUGS 🐛

Please report any bugs on Github: https://github.com/xdp-project/xdp-tools/issues

Like, genuinely please do. Found a bug? Tell them. We're not gatekeeping. 🫶

💖 AUTHOR 💖

Earlier xdp-redirect tools were written by Jesper Dangaard Brouer and John Fastabend. They were then rewritten — for more features, slay — by Kumar Kartikeya Dwivedi, who also ported them to xdp-tools together with Toke Høiland-Jørgensen. This man page was written by Kumar Kartikeya Dwivedi and Toke Høiland-Jørgensen.

okay that's the whole page, bestie, we did it 💅✨

This is from xdp-bench, version V1.6.3, dated FEBRUARY 19, 2026 — so like, extremely fresh. Go forth and benchmark responsibly, no cap. 👑🦋💜

📦 where this page comes from