(13) dpdk, dataplane: RSS, port counters, worker lcores and datapath fixes

[daniel-noland]

Enable RSS across workers and per-lcore mempool caches, export device counters, and reuse receive/pipeline burst storage. Add configurable receive ring depth and packet-header prefetching.

Apply /mtu=N to both drivers, and raise moved datapath interfaces. (Multicast delivery to the control plane now comes from #1928, which marks LLDP and IPv6 neighbor discovery Local.) Keep the fixed 12,188-byte mbuf data room. Expose operator namespace names through symlinks to init's retained descriptors, so the names cannot strand NIC namespaces after exit.

Validation: Clippy across all five affected crates; native DPDK, args, init and stats tests; DPDK doctests; focused dataplane regressions; VM tests for namespace visibility/lifetime and kernel MTU application. Header-prefetch pointer correction produces identical optimized x86-64 instructions. Hardware throughput and physical-NIC restart behavior were not remeasured during review.

Stacked on #1884. Replaces #1824, which GitHub marked merged during the stack re-cut; earlier review discussion remains there.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Essentials
• Run ID: b536f3a7-a62e-4ef8-a82d-aac24c7d52df

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[codecov]

Codecov Report

❌ Patch coverage is 53.30113% with 580 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
init/src/netns_names.rs	2.08%	140 Missing and 1 partial ⚠️
dataplane/src/drivers/dpdk/port.rs	21.60%	98 Missing ⚠️
dataplane/src/drivers/kernel/kif.rs	0.00%	91 Missing ⚠️
init/src/main.rs	0.00%	82 Missing ⚠️
dpdk/src/dev.rs	33.33%	59 Missing and 1 partial ⚠️
dataplane/src/drivers/dpdk/worker.rs	44.89%	27 Missing ⚠️
dataplane/src/drivers/dpdk/mod.rs	0.00%	20 Missing ⚠️
dataplane/src/runtime.rs	35.71%	18 Missing ⚠️
init/src/hugepages.rs	40.00%	12 Missing ⚠️
dpdk/src/mem.rs	88.88%	10 Missing ⚠️
... and 7 more

📢 Thoughts on this report? Let us know!

[mvachhar]

Note

AI-assisted review: This review was drafted with Claude and reviewed by @mvachhar.

Requesting changes for one blocker: with /mtu now configurable, jumbo MTUs silently truncate control-plane frames through the tap (comment on args/src/lib.rs). The pool-sizing comment on port.rs isn't a blocker at the defaults, but please reply to it either way: fix here, or a follow-up.

[mvachhar]

Note

AI-assisted review: This comment was drafted with Claude and reviewed by @mvachhar.

Jumbo MTUs silently truncate control-plane frames. This needs fixing before DPDK ships.

/mtu=N has no upper bound here, the DPDK port takes that MTU, and #1929's dress_one copies it onto the port's tap. But the tap pump still reads into a fixed vec![0u8; TapDevice::MAX_FRAME] of 9216 bytes (dataplane/src/drivers/cpbridge.rs, interface-manager/src/interface/tap.rs). MTU excludes the Ethernet header on both DPDK and Linux, so with /mtu=9216 (common on fabric underlays) the kernel builds frames of up to 9230 bytes, 9234 with a VLAN tag. read(2) on a tap truncates to the buffer and reports success, and the pump injects the truncated frame onto the wire with no error and no counter.

The visible failure is BGP: the kernel derives the session's MSS from the tap MTU, so large UPDATEs go out as truncated, corrupt segments. The peer drops them, TCP retransmits at the same size, and the session stalls or flaps. Before this PR every port ran at 1500, so this couldn't happen; /mtu is what makes it reachable.

Simplest fix: reject /mtu above what the tap path can carry, TapDevice::MAX_FRAME - 18 (9198), with an error that says why. Alternatively, size the pump's buffer from the port MTU, or clamp the tap MTU in dress_one and log it. Either way, please make the limit and the units explicit in MAX_FRAME's doc ("L2 frame, excluding FCS").

[daniel-noland]

Fixed one PR down, in #1927 (547eedd430). TapDevice::MAX_FRAME is now the largest frame a tap can produce: its largest MTU (65535) plus an ethernet header and a VLAN tag. Its doc says so, in those units. read takes a &mut [u8; MAX_FRAME], so the pump can't pass a buffer that truncates. A VM test sends a full-size frame at MTU 9216 through a tap and reads it back whole; it fails with the old 9216-byte constant. So /mtu needs no cap for the tap's sake. The device still clamps it to its own range.

[mvachhar]

Note

AI-assisted review: This comment was drafted with Claude and reviewed by @mvachhar.

The pool size ignores TX rings, so a dead output link can starve a healthy input port. Not a blocker at the defaults, but it becomes one as soon as /rxd is lowered or there are more ports.

4 × rxd × workers covers the RX ring, but a port's RX pool also backs everything it forwards. A packet keeps its original mbuf, so port A's mbufs sit in the TX ring of whichever port the packet leaves on until that NIC completes the descriptor. Per worker, port A's pool can be held by:

Holder	Up to
A's RX ring	rxd
one burst in the pipeline	32
this lcore's mempool cache	256
TX rings of every output port	TX_DESCRIPTORS (1024) × ports

When an output port B loses link, its TX rings stop completing but rte_eth_tx_burst keeps accepting until they fill, so up to 1024 of A's mbufs per worker are stranded until B comes back:

• At the default (rxd = 1024, 4096 per worker) A still has about 1,760 spare after its RX ring, a burst, its cache and the 1024 stranded in B, which is fine.
• At /rxd=256 (1024 per worker), B's rings can absorb A's whole pool. A can't refill its RX ring, and everything arriving on it, BGP and BFD included, is dropped as rx_nombuf because a different link went down.
• Even at the default, the worst case passes 4096 per worker from three ports up.

Could the pool be sized from what actually holds mbufs, e.g. workers × (rxd + MBUF_BURST + cache_size + TX_DESCRIPTORS × ports) plus a small margin for injected control frames? Since this changes how many hugepages the pools need, it'd be good if #1884's per-node hugepage requirement came from the same numbers rather than being a separate fixed figure.

[daniel-noland]

Fixed here, sized from what actually holds mbufs, as you suggest (5b50504273). A port's receive pool now holds, per worker, its receive ring, two bursts (one in the pipeline, one being injected), its cache, and a full transmit ring on every port (args::dpdk_memory::pool_mbufs_per_worker). A dead link can strand at most its rings' worth, so it can't starve another port's receive ring, at any /rxd. #1884's hugepage requirement now comes from the same function, per node and using each interface's /rxd, so the reservation and the pools can't disagree. At the defaults on the BF-3 gateway (two ports, 32 workers) that's 3,456 mbufs per worker instead of 4,096, and the requirement comes to just under 3 GiB.