A software BNG's performance depends on its data path: the route packets take from the wire to the forwarding logic and back. The three realistic ways to build that path on Linux are the kernel network stack, AF_XDP, and DPDK. They differ considerably in throughput and convenience. Netavo BNG supports more than one, each with its own trade-offs.
The kernel stack
The default path. The NIC raises interrupts, the driver builds an sk_buff per packet, and the frame traverses the network stack before your code sees it. Everything standard works: tcpdump, ethtool, any NIC with a mainline driver, no special memory setup.
The cost is per-packet overhead. Interrupts, context switches, socket buffers and the stack's own processing put a hard ceiling on packets-per-second well below what the hardware can move. For a BNG forwarding millions of subscriber packets per second, the kernel stack is not a serious contender for the data path. It remains well suited to the management path (SSH, the control-plane APIs, routing-protocol sockets), which is low-rate and benefits from standard tooling.
AF_XDP
AF_XDP keeps the kernel driver but short-circuits the stack. A small XDP program runs at the driver's receive hook and redirects frames into a user-space memory region (a UMEM) that the data plane reads directly. You skip sk_buff allocation and most of the stack while keeping the NIC bound to its normal kernel driver.
That makes AF_XDP the pragmatic middle ground. It needs no poll-mode driver binding, works with mainline drivers, and coexists with a NIC the kernel still manages. The limitation is hashing: receive-side scaling is the kernel's, configured through ethtool, and mainline drivers hash the outer IP/TCP/UDP tuple only. They do not spread PPPoE frames or the sessions inside one L2TP tunnel across queues, so on AF_XDP those traffic classes pin to one core unless the BNG adds its own software redistribution in front of the workers (which Netavo does; see the note on PPPoE and NIC RSS).
DPDK
DPDK goes all the way to kernel bypass. A poll-mode driver binds the NIC away from the kernel entirely; packets land in huge-page memory, and dedicated cores poll the receive queues in a tight loop with no interrupts. This is the highest-throughput option and the one production carrier data planes use.
It also asks the most of the host. You allocate hugepages, pin and isolate the data-plane cores so the scheduler leaves them alone, and accept that the bound NIC disappears from the kernel's view (tcpdump on it no longer works; the data plane provides its own capture). You also need a supported NIC. On the right card it offloads checksums, and its RSS can hash PPPoE and L2TP-inner sessions in hardware (an Intel E810 with the right DDP package does this), so the traffic spreads across cores without any software help.
One forwarding engine, three back ends
Netavo BNG is built around a Port Abstraction Layer. The entire forwarding pipeline is written once against a single interface (pal.h); the backend (mock, xdp or dpdk) is selected when the data plane is built:
meson setup build_dpdk src/dataplane -Dpal_backend=dpdk # production
meson setup build_xdp src/dataplane -Dpal_backend=xdp # AF_XDP
meson setup build_mock src/dataplane -Dpal_backend=mock # dev / test
The same pipeline code runs on all three. The mock backend has no NIC at all. It is how the data plane is developed and unit-tested on a laptop, while xdp and dpdk are the two you would run in anger. Because the forwarding logic is identical, you can prove behaviour on mock, validate on AF_XDP where binding a NIC is awkward, and deploy on DPDK for line rate, without rewriting the data plane for each.
| Kernel stack | AF_XDP | DPDK | |
|---|---|---|---|
| Throughput | Low | Medium–high | Highest |
| NIC requirement | Any mainline driver | Any mainline driver | Supported poll-mode driver |
| Setup cost | None | Low | Hugepages, core isolation, NIC binding |
| RSS for PPPoE/L2TP | No (software spray needed) | No (software spray needed) | Yes, in hardware on E810+DDP |
| NIC visible to kernel | Yes | Yes | No |
| Best role | Management plane | Constrained / virtualised forwarding | Production line-rate forwarding |
Choosing
- DPDK for a production BNG that must forward at line rate on bare metal, where you can give the data plane isolated cores and run a supported NIC.
- AF_XDP when you cannot or do not want to bind the NIC away from the kernel: on some virtualised or shared hosts, or in an environment where keeping standard kernel tooling on the interface matters more than the last increment of throughput.
- The kernel stack for the management plane only. It is not a data-plane contender at BNG scale.
Whichever you pick, remember that NIC RSS alone does not spread PPPoE or single-tunnel L2TP across cores on AF_XDP or on a plain DPDK NIC. Confirm your data plane redistributes that traffic in software, or you will see one core saturate while the rest idle.
Measure it on your hardware
The free evaluation build is the production build; point it at your NIC and traffic and compare the backends that make sense for your platform. Start at netavobng.com/evaluation; the data-plane design documents ship in the manual.