perf: rewrite critical XDP ICMP/DDoS filter in native eBPF assembly (ASM)

[redlemonbe]

Objective

Rewrite the core XDP packet filtering routine in raw eBPF assembly to eliminate LLVM compiler overhead and push packet-drop latency toward the nanosecond range.

Motivation

The current C-compiled eBPF path goes through the LLVM backend, which introduces:

• Unpredictable register allocation
• Missed optimization opportunities at the instruction level
• Occasional redundant bounds checks inserted by LLVM

For the hot path (IPv4 header parse → source IP lookup in icmp_banned → XDP_DROP), hand-written eBPF ASM gives deterministic instruction counts and exact control over every register.

Scope

1. Isolate the drop/routing function

Extract the logic that:

• Reads the incoming packet via xdp_md context (data / data_end pointers)
• Parses the Ethernet + IPv4 headers
• Looks up ip->saddr in BPF_MAP_TYPE_LRU_HASH (icmp_banned)
• Returns XDP_DROP on a hit, XDP_PASS or redirects otherwise

2. Translate to raw eBPF ASM

Use explicit eBPF register semantics:

• r1 — xdp_md *ctx on entry
• r0 — return value (XDP_DROP = 1, XDP_PASS = 2)
• r2–r5 — scratch / helper arguments
• r6–r9 — callee-saved across helper calls
• r10 — read-only frame pointer

Every instruction must be commented with its register role and purpose.

3. Pass the kernel verifier

• All memory accesses via data/data_end must include explicit bounds checks before each load.
• No unbounded loops.
• Stack usage ≤ 512 bytes.
• Helper calls (bpf_map_lookup_elem) must follow the standard calling convention.

4. Rust control-plane integration

• The ASM object must be loadable by aya (EbpfLoader) alongside the existing C-compiled sections.
• No changes to the map definitions or Rust-side accessors.

Expected output

A fully commented eBPF ASM implementation of the ICMP/DDoS filtering function, validated by the Linux verifier, integrated into the existing build system (build.rs), with benchmarks showing instruction-count reduction vs the LLVM-compiled baseline.

Labels

enhancement performance ebpf xdp

[x0tta6bl4-ai]

Hi @redlemonbe,

Interesting approach with raw eBPF ASM. I've been working on XDP programs for packet filtering and have some thoughts on the tradeoffs:

When ASM beats LLVM-compiled C

• Deterministic instruction count — LLVM sometimes inserts redundant bounds checks. ASM gives exact control.
• Nanosecond latency — for the hot path (parse → lookup → drop/pass), every cycle counts.
• Predictable register pressure — no surprises from register allocator.

When to stick with C

• Maintainability — ASM is harder to review and modify.
• Portability — LLVM handles different target backends.
• Complex logic — if you need map lookups, tail calls, or helpers, C is cleaner.

Practical tip for your ICMP filter

For the icmp_banned LRU hash lookup, consider adding a fast-path check before the full parse:

; Quick check: is this even IPv4?
ldxh [r1 + 12]        ; load ethertype
jne #0x0800, pass      ; not IPv4 → pass

; Now do the full parse + lookup

This skips the IP header parsing entirely for non-IPv4 traffic (ARP, IPv6, etc.), which can be 30-50% of packets on some networks.

Benchmark tip

When measuring nanosecond latency, use bpf_ktime_get_ns() at entry and exit:

u64 start = bpf_ktime_get_ns();
// ... filter logic ...
u64 elapsed = bpf_ktime_get_ns() - start;
bpf_map_update_elem(&latency_hist, &bucket, &count, BPF_ANY);

This gives you a histogram of per-packet processing time.

Happy to compare approaches if you want to benchmark against a C-compiled version.

[redlemonbe]

Thanks @x0tta6bl4-ai — this is exactly the kind of input I hoped #146 would attract, and your pros/cons list basically answers the question I opened it for.

Context on the current state: today the filter is C (ebpf/dns_xdp.c, clang-compiled) — #146 is the proposal to hand-write the critical ICMP/DDoS path in native eBPF ASM. So your tradeoff table is precisely the decision I'm weighing, and reading it against what the filter actually does, I think your "stick with C" column wins here, for two concrete reasons:

• The ICMP/DDoS path is map- and helper-bound, not instruction-bound. The hot decision is an icmp_banned LRU-hash lookup → per-source LRU rate-limit → percpu stats (feat: XDP ICMP handler — intercept ping before kernel, rate-limit per source IP #89). Those are helper calls; their cost dominates and is identical in ASM or C. ASM's wins (deterministic instruction count, register pressure) mostly pay off on a pure parse→drop path with no maps — which this isn't. It's your own "complex logic → C is cleaner" case.

• The BPF isn't the bottleneck. On the current rig the fast path is link/line-rate bound at ≤24 % receiver CPU (numbers under docs/benchmark/) — the program has cycles to spare. Shaving BPF instructions wouldn't move throughput until a faster NIC or more links make the program the wall.

Two of your micro-tips are already in place, FWIW: the program gates on ethertype before the full parse (reads h_proto, branches IPv4 / IPv6 / 802.1Q, XDP_PASS for anything that isn't UDP/53 — we keep the IPv6 path rather than dropping non-IPv4, since we serve DNS over v6), and the icmp_banned LRU drop runs before the rate-limit check. The bpf_ktime_get_ns() per-section histogram is a nice one I hadn't wired in — that's exactly the measurement that would justify (or kill) an ASM rewrite section by section.

So I'm going to keep #146 open but not immediate: the data says the BPF isn't where the time goes, and the DDoS filter is the map-heavy case where C earns its keep. If a future rig makes the program the bottleneck, the per-section bpf_ktime histogram is step one, and I'd genuinely like to benchmark an ASM version of the parse path then. Thanks for the thoughtful comment.