# rdma-core: the userspace half of Linux RDMA, and how to build it from source > rdma-core ships the userspace libraries and daemons that sit on top of the kernel's drivers/infiniband subsystem. It is a C project built with cmake, released as rdma-core-65.0, and it is the package most people mean when they search for rdma core install. **linux-rdma/rdma-core** — RDMA core userspace libraries and daemons - Repository: https://github.com/linux-rdma/rdma-core - Stars: 2,379 · Forks: 911 - Language: C - License: NOASSERTION - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/linux-rdma-rdma-core ## What rdma-core actually is, and who ends up installing it The README opens with a sentence that defines the boundary of the project: this is the userspace component for the Linux kernel's drivers/infiniband subsystem. That boundary is the whole story. The kernel drivers live elsewhere; rdma-core provides the libraries that user programs link against to reach them. Concretely, the README names three device nodes and the library that owns each one. libibverbs talks to /dev/infiniband/uverbsX. librdmacm talks to /dev/infiniband/rdma_cm. libibumad talks to /dev/infiniband/umadX. If your program opens one of those nodes, it is almost certainly doing so through one of these libraries. The audience follows from that. This is not a library you reach for because you want fast networking in the abstract. It is the layer under MPI stacks, storage transports, and anything else that needs queue pairs and completion queues on InfiniBand, RoCE or iWARP hardware. Distribution maintainers are the other large audience: the repository carries debian/, redhat/ and suse/ directories, so the packaging lives in-tree alongside the code. ## Providers, device nodes and the daemons that run in the background The architecture visible in the repository is a provider model. Under providers/ sits the userspace half of each kernel RDMA driver, and the README lists the kernel modules those providers support, including mlx5_ib.ko, mlx4_ib.ko, iw_cxgb4.ko, hfi1.ko, qedr.ko, bnxt_re.ko, efa.ko, erdma.ko, irdma.ko, ionic_rdma.ko, mana_ib.ko, ib_qib.ko, ib_mthca.ko, ocrdma.ko, hns-roce-hw-v2.ko, vmw_pvrdma.ko, rdma_rxe.ko and siw.ko. A libibverbs application does not name a vendor; it asks for a device, and the matching provider supplies the verbs implementation for that device. The two software drivers in that list matter for anyone without hardware. rdma_rxe and siw are kernel modules that implement RDMA over an ordinary network interface, so you can exercise the same userspace stack without a card. Beyond the libraries, the README describes three service daemons. srp_daemon works with ib_srp.ko, the SCSI RDMA protocol target. iwpmd serves iWARP kernel providers. ibacm is described as an InfiniBand communication management assistant. These are not optional decoration: iWARP setups in particular depend on iwpmd being present, which is why it is a separate top-level directory rather than a subdirectory of a library. The remaining top-level entries show the rest of the surface: libibmad, libibnetdisc and infiniband-diags for fabric diagnostics and subnet management, pyverbs for Python bindings, rdma-ndd and rdma-sysusers.conf for node description and user setup, plus util/ and tests/. The kernel-headers/ and kernel-boot/ directories exist so the userspace build can track the kernel ABI it depends on. ## Building rdma-core from source with build.sh The README gives a cmake-based build and a one-line quick start. It also states a constraint that surprises people: the build is configured to run all the programs in place and cannot be installed. So build.sh is a developer and test path, not a deployment path. ```bash bash build.sh ``` After that, per the README, build/bin holds the sample programs and build/lib holds the shared libraries. Because the tree is not installable, you run the samples from where they land rather than copying them into /usr/local. Dependencies differ by distribution. On Debian-derived systems the README lists this set: ```bash apt-get install build-essential cmake gcc libudev-dev libnl-3-dev libnl-route-3-dev ninja-build pkg-config valgrind python3-dev cython3 python3-docutils pandoc ``` Fedora and CentOS 8 use the spec file instead, with dnf builddep redhat/rdma-core.spec. openSUSE has its own zypper line. CentOS 7 and Amazon Linux 2 are treated separately, and the README points developers there toward newer tooling: on CentOS 7 you add epel-release and then cmake3, ninja-build and pandoc, and on Amazon Linux 2 you enable epel through amazon-linux-extras and install the same trio. The README notes that EPEL names the command ninja-build rather than ninja, and cmake3 rather than cmake, which is the kind of detail that otherwise costs an afternoon. If you are not building from source, the repository's debian/, redhat/ and suse/ directories are where the distribution packages are defined, and the README points to Documentation/stable.md for the stable release process. ## A first real use: software RDMA on an existing interface The most useful thing in the README for a newcomer is the software RDMA recipe, because it lets you verify the stack without owning an RDMA card. You pick a driver, rdma_rxe or siw, and a matching type, rxe or siw, then attach it to a network device. ```bash modprobe rdma_rxe rdma link add rxe0 type rxe netdev eth0 ``` Substitute your own interface name for eth0. The README warns that the iproute2 version must be recent enough for the rdma link command to work, so an older distribution can fail here even with everything else in place. To confirm the device appeared, the README offers two checks: ```bash ibv_devices rdma link ``` Either one should show the device you just added. If ibv_devices lists nothing, the provider did not bind to the device, and adding more configuration on top will not help. When something does break, the README is specific about where bugs go: the linux-rdma@vger.kernel.org mailing list. A useful report includes the Linux distribution and version, the kernel version, the InfiniBand hardware and firmware version, the steps to reproduce, and, for a crash, the exact output including kernel messages. That list is worth reading as a statement about the project's support model. There is no issue tracker workflow described in the README; patches are covered separately in Documentation/contributing.md. ## Where rdma-core is the wrong tool The clearest limitation is portability. This is userspace for the Linux kernel's drivers/infiniband subsystem, and the device nodes it targets are Linux device nodes. If your codebase has to run on Windows, this is not the layer you build on, and no amount of abstraction inside libibverbs changes that. The second limitation is that the quick start build cannot be installed. Anyone who runs build.sh expecting a normal install step will find the README explicitly rules it out. That pushes real deployments toward distribution packages, which means the version you get is the version your distribution shipped, not the version you just compiled. The third is the provider model itself. libibverbs gives you a common verbs interface, but behaviour still depends on which kernel driver and firmware sit underneath. A problem that reproduces on mlx5_ib.ko may not reproduce on siw.ko, and the README's bug template asks for hardware and firmware version precisely because that context is not optional. Finally, consider the scope of what you are pulling in. rdma-core is not a small utility library. It includes providers for eighteen kernel drivers, three daemons, diagnostic libraries, Python bindings and in-tree packaging for three distribution families. If you only need a diagnostic command, taking the distribution package is far less work than building the tree. ## How it relates to the kernel and to other userspace stacks The natural comparison is between rdma-core and the kernel tree it serves. The README draws the line itself: this repository is the userspace component, and the kernel drivers/infiniband subsystem is the other half. A change in the kernel ABI can require a matching change here. The presence of kernel-headers/ and kernel-boot/ in the repository is a direct consequence of that coupling, and it is why the project tracks kernel versions rather than treating them as an external detail. The second comparison is between rdma-core and a socket-based networking stack. A TCP application goes through the kernel's socket layer and copies data through it. An RDMA application using libibverbs works with queue pairs and completion queues exposed through the uverbs device node, with the provider translating those verbs into hardware operations. That is a different programming model, not a faster version of the same one. It is also why the software drivers exist: rdma_rxe and siw let you run the RDMA model on a plain interface, which is useful for development and for testing code paths that would otherwise need a card. The third comparison is between the libraries inside the project. libibverbs is the verbs layer. librdmacm handles connection management through /dev/infiniband/rdma_cm. libibumad handles management datagrams through /dev/infiniband/umadX. libibmad, libibnetdisc and infiniband-diags serve fabric diagnostics and discovery. Choosing between them is choosing which device node your program needs, and the README's list of nodes is the fastest way to make that decision. ## Maintenance, releases and licence files The repository is not archived, and the last push was on 2026-09-22. Releases are frequent and tagged: v65.0 on 2026-09-06, v64.0 on 2026-07-08, and v63.1 on 2026-07-07. The README describes stable versions as being released regularly with backported fixes, documented in Documentation/stable.md, and states that the current minimum version still maintained is v33.X. That number is the one to check before you pin a branch, because it moves. Upgrade cost depends on which half you are on. If you consume distribution packages, the debian/, redhat/ and suse/ directories in the repository are the packaging definitions, and your upgrade cadence is your distribution's. If you build from source, build.sh produces an in-place tree that cannot be installed, so upgrading means rebuilding and re-running from build/bin and build/lib. If you maintain a provider or a downstream patch, the stable branch policy in Documentation/stable.md governs which fixes reach which release line. The licence situation needs care. The repository root carries COPYING.BSD_FB, COPYING.BSD_MIT, COPYING.GPL2 and COPYING.md, which means the tree is not under a single identifier; the project metadata reports the licence as NOASSERTION rather than naming one. Different parts of the tree can therefore fall under different terms. Read COPYING.md and the individual file headers before you redistribute anything, and treat the presence of multiple COPYING files as a signal to check rather than a formality. Nothing here is legal advice. ## Conclusion Adopt rdma-core if you are writing or packaging an application that talks to /dev/infiniband device nodes, or if you need the daemons that back ib_srp, iWARP and InfiniBand connection management. Do not adopt it if you expected a portable RDMA API for Windows or macOS: the README describes userspace for the Linux kernel subsystem, and the supported releases listed are Debian 9 and newer and Ubuntu 16.04 LTS and newer. Before you commit to a branch, check Documentation/stable.md for the current minimum maintained version, which the README states is v33.X, and decide whether you are building from source or taking the distro package. ## FAQ ### What is rdma-core? It is the userspace component for the Linux kernel's drivers/infiniband subsystem. The README states that it contains the userspace libraries for /dev/infiniband/uverbsX (libibverbs), /dev/infiniband/rdma_cm (librdmacm) and /dev/infiniband/umadX (libibumad), plus service daemons such as srp_daemon, iwpmd and ibacm. ### What is RDMA and how does it work? The README does not explain RDMA as a concept; it documents the userspace libraries for the Linux kernel's drivers/infiniband subsystem. What it does show is the mechanism at the device level: libibverbs drives /dev/infiniband/uverbsX, librdmacm drives /dev/infiniband/rdma_cm, and libibumad drives /dev/infiniband/umadX, with per-driver userspace support under providers/. ### What hardware is needed for RDMA? The README lists userspace providers for many kernel RDMA drivers, including mlx5_ib.ko, mlx4_ib.ko, iw_cxgb4.ko, hfi1.ko and qedr.ko, so supported hardware spans several vendors. It also documents a software path through rdma_rxe and siw, which set up RDMA on an existing interface without a card. ### What is RDMA vs TCP? The README does not compare the two directly. What it documents is that an RDMA program reaches the kernel through device nodes such as /dev/infiniband/uverbsX rather than through the socket layer, and that the software drivers rdma_rxe and siw can run that model over an ordinary network interface. ### What is RDMA vs DMA? The README does not address DMA on its own. It describes the userspace side of the kernel's drivers/infiniband subsystem, listing the libraries for /dev/infiniband/uverbsX, /dev/infiniband/rdma_cm and /dev/infiniband/umadX and the kernel drivers those libraries support. ## Sources - [Issues](https://github.com/linux-rdma/rdma-core/issues) - [linux-rdma/rdma-core on GitHub](https://github.com/linux-rdma/rdma-core) - [README](https://github.com/linux-rdma/rdma-core/blob/master/README.md) - [Releases](https://github.com/linux-rdma/rdma-core/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/linux-rdma-rdma-core