Agentic NIC Dataplane Lab

Why agentic AI changes the NIC story

Traditional microservices and one-shot inference systems make networking feel secondary. The model dominates the discussion. The GPU dominates the budget. The host path is often treated as a generic transport layer that can be optimized later.

Agentic systems break that assumption.

The repo’s core framing is exactly right here: agentic AI becomes a queueing and copy problem at scale. That is not just a slogan. It is a statement about what you must measure on real systems:

• softirq CPU time
• queue-to-core locality
• copy and bounce-buffer pressure
• completion delivery latency
• host CPU consumed per GB moved

The tri-path dataplane is the right abstraction

The most durable idea in the repository is the tri-path split.

That split is not just architecturally neat. It creates a benchmarkable hypothesis. For each path, the repo asks a measurable question:

• Can Path A keep mainstream agent RPC simple while pushing copy and wakeup cost down enough?
• Can Path B actually beat Path A for the hot queue classes that justify bypass-like complexity?
• Can Path C cut CPU cost for sustained bulk state traffic enough to justify its setup burden?

What the repo actually implements today

The repo is still an early lab, but it is early in the right way. It contains enough code to teach the initialization shape of each path without pretending the hard parts are already complete.

AF_XDP starter path

The current AF_XDP sample goes beyond a bind-only stub. It now shows the real conceptual lifecycle:

• UMEM allocation and locking
• fill-ring prepopulation
• RX ring polling
• frame recycling back into the fill ring
• completion-ring recycling for TX completion paths

#if defined(__has_include)
#  if __has_include(<xdp/xsk.h>)
#    include <xdp/xsk.h>
#  elif __has_include(<bpf/xsk.h>)
#    include <bpf/xsk.h>
#  else
#    error "AF_XDP userspace headers not found"
#  endif
#endif

static int configure_umem(struct afxdp_runtime *rt)
{
    struct xsk_umem_config cfg;
    size_t umem_size = (size_t)NUM_FRAMES * FRAME_SIZE;

    memset(&cfg, 0, sizeof(cfg));
    cfg.fill_size = FQ_RING_SIZE;
    cfg.comp_size = CQ_RING_SIZE;
    cfg.frame_size = FRAME_SIZE;

    posix_memalign(&rt->buffer, getpagesize(), umem_size);
    mlock(rt->buffer, umem_size);

    return xsk_umem__create(&rt->umem,
                            rt->buffer,
                            umem_size,
                            &rt->fq,
                            &rt->cq,
                            &cfg);
}

This is exactly the kind of scaffold that helps people cross the gap between “I know AF_XDP exists” and “I understand the rings, frames, and ownership model enough to reason about it.”

io_uring receive path

The io_uring sample is intentionally modest, but the repo made the right compatibility move: it does not blindly assume the newest helper wrappers are available. That matters because real Linux networking work is full of version mismatches between kernel capability, userspace headers, and distribution packaging.

io_uring_prep_recv(sqe, sockfd, buf, sizeof(buf), 0);
#ifdef IORING_OP_RECV_ZC
    sqe->opcode = IORING_OP_RECV_ZC;
    using_recv_zc = true;
#endif

ret = io_uring_submit(&ring);
ret = io_uring_wait_cqe(&ring, &cqe);

That is a small but important sign of maturity: the repo is not only about architecture ideas, it is also dealing with the actual ugliness of Linux build and packaging reality.

RDMA starter path

The verbs sample remains a starter, but it correctly centers memory registration and queue-pair setup as the real conceptual boundary.

pd = ibv_alloc_pd(ctx);
cq = ibv_create_cq(ctx, 128, NULL, NULL, 0);

attr.qp_type = IBV_QPT_RC;
attr.cap.max_send_wr = 128;
attr.cap.max_recv_wr = 128;

qp = ibv_create_qp(pd, &attr);
mr = ibv_reg_mr(pd,
                buf,
                sizeof(buf),
                IBV_ACCESS_LOCAL_WRITE |
                IBV_ACCESS_REMOTE_READ |
                IBV_ACCESS_REMOTE_WRITE);

The repo is honest that the rest of the work still matters: the full RESET → INIT → RTR → RTS state machine and peer exchange are still ahead.

What the benchmark and results story gets right

The repository is unusually explicit about benchmark honesty.

Instead of vague “faster networking” claims, it defines workload classes that actually resemble agent traffic:

• Class A: small agent RPC and fan-out traffic
• Class B: retrieval and memory-service traffic
• Class C: bulk east-west state movement

It also emits JSON result envelopes rather than just console screenshots, and it already contains an illustrative E810 baseline artifact plus a plotting script. That is a healthy design choice, because systems work ages badly when results are not machine-readable.

The agentic NIC extension is what makes this repo more than a dataplane lab

Many repositories stop at transport optimization. This one does not. It makes a second leap: from “which Linux path should carry the bytes?” to “what if selected dataplane decisions move closer to the NIC itself, but inside a bounded safety envelope?”

That is where the repo’s newer architecture docs become genuinely differentiated.

That architecture matters because it addresses the obvious failure mode directly: if you say “agentic NIC” too casually, everyone reasonably imagines a control loop that can destabilize queues, violate fairness, or hide its own mistakes. The repository’s answer is the Guardian layer and the audit model.

• The Guardian is the deterministic shell that prevents unsafe dataplane actions.
• The Audit layer makes decisions inspectable and non-forgeable.
• The tenant quota model prevents one local optimization loop from becoming another tenant’s starvation event.

tracepoint:sched:sched_wakeup
/comm == "guardiand"/
{
  @guardian_wakeups = count();
}

tracepoint:sched:sched_switch
/prev_comm == "guardiand" || next_comm == "guardiand"/
{
  @guardian_switches = count();
}

Even the tracing hooks matter here. The repo is no longer saying “trust the guardian.” It is moving toward “instrument the guardian.”

What still has to be proven before this idea grows up

The repo also does something that many ambitious systems projects avoid: it names its own release blockers clearly.

This kind of explicit self-critique makes the project stronger, not weaker. It tells future contributors where the hard work still is, and it keeps the repo from overselling partial implementations as finished systems.

Why this repo matters

Agentic-NIC-Dataplane-Lab matters because it sits in a very useful middle layer. It is concrete enough to compile, benchmark, and extend. But it is also ambitious enough to ask what happens after transport optimization, when network policy itself becomes more local, more autonomous, and more safety-critical.

That makes it interesting to three different audiences at once:

• Linux performance engineers who want to reason about queue ownership, copies, and completion paths.
• AI infrastructure teams who need a sane way to compare kernel TCP, AF_XDP, and RDMA without cargo culting any of them.
• systems architects and patent thinkers who care about bounded autonomous NIC behavior, Guardian layers, reasoning logs, and multi-tenant control.

Repository links worth reading first

• Agentic-NIC-Dataplane-Lab repository
• README.md
• Reference architecture
• Agentic NIC architecture
• Safety and guardrails
• Reasoning log design
• Benchmark plan
• AF_XDP starter path
• io_uring receive starter
• RDMA verbs starter