Demikernel, one system call API across RDMA, DPDK and XDP

The idea is one API over several very different devices

Demikernel is a library operating system architecture designed for use with kernel-bypass I/O devices. The architecture offers a uniform system call API across kernel-bypass technologies such as RDMA and DPDK, and OS functionality such as a user-level networking stack for DPDK.

That is the whole proposal in one sentence, and it is a proposal about the application layer rather than about the transport. Kernel-bypass means the application talks to the NIC or the RDMA device directly, without the kernel's network stack in the path. The problem that creates is that each technology has a different programming model, so an application written for one has to be rewritten for another. Demikernel's contribution is a library that sits above the different device models and exposes one set of system calls, so the application is written once.

The motivation is written up in a blog post, and the system itself was published at SOSP '21, with the paper linked by its DOI. Both are in the README, along with a pointer to aka.ms/demikernel for more reading.

The implementation is Rust, and the Cargo.toml describes the package as the Kernel-Bypass LibOS Architecture, at version 1.5.13 with edition 2021. The crate is built as both a cdylib and an rlib, and the lib.rs path is src/lib.rs. The project's own crates are published on crates.io and pulled in as dependencies: demikernel-dpdk-bindings at 1.1.8, optional, and demikernel-network-simulator at 0.1.0, which is not optional.

That last dependency is the one that tells you how the project is meant to be developed. A network simulator is always in the dependency tree, which means the normal way to run the code is against a simulated network rather than against hardware, and the same simulator is what the test suite uses. The release tags tell the same story in reverse. v1.3 from 2023-06-30 is the Stable Catmem LibOS, v1.4 from 2023-11-13 is the Stable Catloop LibOS, and v1.5 from 2024-05-17 is the Demikernel v1.5, so the codenames of the LibOSes appear in the release history.

Three LibOSes, three different kernel-bypass paths

The LibOS codenames are listed in the README, and each one names a device technology.

catnap is the Linux Sockets and Windows Winsock LibOS. catnip is the DPDK LibOS. catpowder is the Linux Raw Sockets and Windows XDP LibOS.

The pairing is the interesting part, because it shows the two axes the design is trying to cover. There is a technology axis, spanning RDMA-style kernel bypass through DPDK, raw sockets, XDP and the ordinary socket API, and there is an operating system axis, since Linux and Windows each appear in two of the three LibOSes.

That combination is what the uniform system call API has to bridge. A program that opens a socket, connects, sends and receives should not care whether the bytes went out through the Windows Winsock path, through DPDK polling a NIC, or through XDP on Linux. The badges at the top of the README show continuous integration workflows per LibOS, one each for catnip, catnap and catpowder, which means the three are tested independently and can diverge in their support.

The Windows support is more than a port, and the Cargo.toml explains why. There is a Windows-specific dependency block, and the comment says the libc implementation in Rust is quite different for Windows and Linux, and this library provides the relevant networking constants and data structures for Windows. The windows crate is pulled in with a set of features, Win32_Foundation, Win32_Networking_WinSock, Win32_Security, Win32_Storage_FileSystem, Win32_System_IO, Win32_System_Pipes, Win32_System_SystemInformation and Win32_System_Threading, which is the feature list of what a socket library actually touches on Windows. There is a separate demikernel-xdp-bindings at 1.0.1, optional, and windows-sys alongside it for interacting with socket2.

The build system reflects the same dual-platform reality. The top level Makefile contains what it calls a trick to enable portability across MAKE and NMAKE, and the comment explains that MAKE recognizes line continuation in comments but NMAKE does not, so the include of windows.mk is written in a way that NMAKE will not try to interpret.

A network simulator in the dependency tree, and what the tests look like

The demikernel-network-simulator crate is a mandatory dependency, and that single fact shapes the whole development experience.

A LibOS that talks to a NIC through DPDK needs real hardware, or at least a device model, to be exercised at all. Shipping a simulator as a required dependency means the alternative path is the default one: you can run the whole system, the tests and the examples, without a NIC, and against the simulator the network behaves predictably. The repository has a network_simulator/ directory at the top level, which is where that crate lives, and dpdk_bindings/ and xdp_bindings/ directories for the device bindings that the simulator stands in for.

The examples/ directory shows what a program against the API looks like. There is a tcp-echo/ project, which is the canonical first example for a network stack, a tcp-wait/ project, a tcp-close/ project, and separate c/ and rust/ directories, which tells you the API is intended to be usable from C as well as from Rust, even though the implementation is Rust.

The tests/ directory at the top level holds the test suite, and the Cargo.toml declares test targets with names beginning with tcp-, so the tests are organised by protocol behaviour rather than by module.

The documentation layout is unusually complete for a project of this kind. doc/setup.md covers the development environment setup, doc/building.md covers building on Linux and doc/building-windows.md covers Windows, doc/testing.md covers testing and running, and doc/cloudlab.md covers running on CloudLab. The API documentation is in the man/ directory, which is the man page convention rather than the generated-doc convention, and CONTRIBUTING.md is at the repository root.

There are also top level directories for benchmarks/, scripts/, tools/, include/ and src/, plus a rust-toolchain file that pins the toolchain, a rustfmt.toml, linux.mk and windows.mk as the two platform make fragments, and a.githooks/ directory.

What the README promises, and what it explicitly does not

The Usage Statement is the paragraph to read before anything else, and it is unusually direct. This project is a prototype. As such, we provide no guarantees that it will work and you are assuming any risks with using the code. The project welcomes comments and feedback, and gives two maintainers to send them to, Irene Zhang and Anand Bonde, both at Microsoft.

There is a consent clause attached to that feedback too. By sending feedback, you are consenting that it may be used in the further development of the project. That is a routine clause in a research project, and it is the kind of detail that distinguishes a research artefact from a product.

There is a separate Trademark Notice, which says the project may contain trademarks or logos for projects, products or services, that authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark and Brand Guidelines, that use of Microsoft trademarks or logos in modified versions must not cause confusion or imply Microsoft sponsorship, and that any use of third-party trademarks or logos is subject to those third party's policies.

That last point is the one to hold on to if you plan to fork. The code is MIT, and the licence file is LICENSE.txt with a NOTICE.md alongside it. But the trademark clause is a separate constraint on how you present it, and it applies to modified versions.

The repository also carries SECURITY.md and SUPPORT.md, and a CODE_OF_CONDUCT.md. For a prototype with a stated absence of guarantees, having a security file and a support file is a reasonable signal about how the project wants to be approached.

The default branch is dev, the last push was on 2026-07-23, and the project is not archived. The homepage is aka.ms/demikernel and the repository has no separate website beyond that redirect and the linked paper and blog post.

Editorial conclusion

Demikernel suits a networking researcher who wants to write one application against RDMA, DPDK or raw sockets without rewriting it per technology, and it suits a systems programmer who needs a user-level stack that does not depend on the Linux kernel network path. It is the wrong choice for production use, because the README calls it a prototype and provides no guarantees, and it is the wrong choice if you need a normal POSIX environment, since a LibOS deliberately provides only a small system call surface. Before experimenting, read doc/setup.md for the development environment and doc/testing.md for how to run the test suite, and use the network_simulator rather than real hardware for a first pass, since that is what the repository's own testing setup is built around.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/demikernel on GitHub
3. Project website
4. README
5. Releases