Measured, not marketed

Same bytes. Three compilers.

C, typed Nelua, and Odin walk the same caller-owned SDB1 bytes through the same fixed-width ABI. The result is workload-specific: Odin leads complete valid-packet classification here, while Nelua leads the scan rows and C remains close on the alignment and malformed rings. The measured valid scan/classifier paths recorded zero allocator activity across the six intercepted APIs.

See the measured rows ↓Open the accessible tablesReturn to the network model
61,682correctness assertionsincluding differential checks · zero failures
0 Ballocated in every peer2,000,000 measured operations each
18.06 nsOdin portable valid classifypayload 0 · p50 batch mean
473XDP instruction slotsNelua-generated C artifact

One honest machine snapshot

There is no universal winner.

31 CPU-pinned samples per row on an Intel i5-10400 Alpine worker. Lower latency is better. Timing never gates CI, and this is not a NIC or cryptographic benchmark.

Complete valid packet

Odin portable · 55.4–59.3 M/s

The four payload fixtures span 16.87–18.06 ns/record. The classifier touches bounded headers rather than walking the payload body; fixture-to-fixture variation is not payload bandwidth.

64-alignment scan ring

Nelua portable · ~72.9 M/s

It records 13.72 ns/record; C tuned follows at 13.75 ns, tuned Nelua at 13.96 ns, and tuned Odin at 14.34 ns. The same Nelua portable lane leads the separate hot scan at 13.46 ns.

Sixteen rejected statuses

Nelua portable · ~177.3 M/s

Its malformed-ring p50 batch mean is 5.64 ns/record, with C portable at 5.82 ns/record. Every entry is non-OK, including payload- and record-limit rejection.

Tuned lane

Measure before believing

Odin tuned leads the mixed classifier at about 7.69 ns and improves Odin’s hot/alignment scans, yet regresses its malformed scan and payload-0 valid from 18.06 to 18.16 ns. This sequential snapshot is observational, not a universal compiler verdict.

Grouped horizontal bars of C, Nelua, and Odin record throughput for portable and tuned fixed-scan and classifier workloads.
Throughput is derived from the median of usable raw timing samples. Payload-size rows stay almost flat because classification never walks payload bytes.
Latency chart showing the median and p99 of batch-mean nanoseconds per operation for C, Nelua, and Odin benchmark rows.
The outlined marker shows run-to-run dispersion of batch means, not per-record tail latency. All published rows recorded zero CPU migrations after the harness pinned itself to CPU 0.

Ownership made visible

Zero is a measured result.

The harness wraps malloc, calloc, realloc, aligned_alloc, posix_memalign, and free. Odin also builds with a panic allocator; both language objects have no undefined symbols.

Allocation graph showing zero calls and zero bytes per operation for all portable and tuned C, Nelua, and Odin variants.
Each variant completed one million scan iterations plus one million full classifier iterations: zero calls, zero requested bytes, zero frees.
Borrowed does not mean immortalThe result owns offsets, not packet bytes. An AF_XDP UMEM frame or other receive buffer must remain leased and immutable until authentication, policy checks, and every payload read finish.

Size without sleight of hand

Compare like with like.

Each implementation now has its own object; the identical timing harness is excluded. Maintained source, generated C, object file, size-reported text aggregate, and exact exported symbols remain separate quantities.

Code-size chart comparing maintained source, generated C, object, size-reported text aggregate, and exported symbol bytes for C, Nelua, and Odin variants.
The size tool's text value is an aggregate, not a claim about the literal ELF .text section. C source bytes are intentionally blank because its implementation spans the wrapper and shared wire header; the raw input manifest records both. None of these numbers includes crypto or application policy.

Kernel boundary

Odin is a userspace peer, not a pretend BPF target.

The official Odin compiler has no supported BPF/eBPF target. Retargeting x86 LLVM IR would discard the supported ABI and verifier contract, so the site marks that cell not applicable.

NELUA → C → BPF

Inspectable XDP artifact

  • 3,784-byte xdp section
  • 473 encoded instruction slots
  • 432 maximum observed stack bytes
  • no internal-call relocation
  • direct record + 64 bounds-check pattern observed
ODIN → NATIVE OBJECT

Independent userspace implementation

  • raw pointer + explicit byte length
  • borrowed spans represented as offsets
  • no imports or allocator symbols
  • panic-allocator build contract
  • BPF status: not applicable
Still not authenticationXDP may reject, classify, rate-limit, or redirect a candidate. Kernel verifier and real-NIC status remain not_run; userspace must still verify the MAC/signature and complete policy.
Evidence boundaryThe checked verifier proves commit-bound inputs, internally consistent counters, and exact deterministic rendering. It cannot prove that a machine honestly performed the measurement without a separate signed external attestation. Only Odin is tied to a reviewed release asset; the recorded C/LLVM/binutils hashes describe ambient observational tools, not a hermetic trusted toolchain.
Read every measured row →Reproduce on a self-hosted machine ↗