Hi HN,

I’ve been experimenting with how far NIC receive latency can be pushed on commodity hardware when you bypass the kernel and treat the NIC as memory-mapped hardware instead of a network device.

This is a research / measurement project, not a complete networking stack.

What I’m measuring: • ~20–50ns NIC RX → userspace visibility (device-dependent) • Busy-polling descriptor rings via MMIO • Zero-copy DMA buffers • No syscalls, interrupts, or kernel networking

Public repo: https://github.com/krish567366/BareMetalNIC

Docs / notes: https://baremetalnic.krishnabajpai.me

Important clarification: The public code focuses on instrumentation, register access, and timing methodology. Some experimental logic and tuning paths are intentionally not published yet.

This is mainly about how to measure and reason about latency accurately at this scale, not claiming a drop-in replacement for DPDK or kernel stacks.

Questions I’d genuinely like feedback on: 1. Where do you usually see the first sources of jitter below ~100ns? 2. On ARM64, how much penalty do you typically expect from memory ordering? 3. Any recommended techniques for validating RX timestamps externally?

Happy to clarify methodology or measurements.

This is very obviously all generated using AI, borderline slop.

The docs directory is entirely missing. I don’t see how or where the software actually performs any measurements. The readme claims there’s a benchmarking folder but I don’t see that either. So, what methods did you use to measure timing/latency?

Maybe there’s some application for this but I’m not sure what it is. By the time you start parsing those rx bytes from the nic, I have to imagine the numbers start looking closer to DPDK.