# VMA, Mellanox's user space socket acceleration over RDMA adaptors

> libvma is the source for NVIDIA Messaging Accelerator, a Linux user space library that lets applications written against the standard socket API run over Ethernet or InfiniBand with the network stack bypassed. It targets message based and streaming workloads such as market data systems and Web2.0 clusters, and it is a hardware dependent library rather than a drop-in performance switch.

**Mellanox/libvma** — Linux user space library for network socket acceleration based on RDMA compatible network adaptors

- Repository: https://github.com/Mellanox/libvma
- Website: https://www.mellanox.com/products/software/accelerator-software/vma?mtag=vma
- Stars: 690 · Forks: 171
- Language: C++
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/mellanox-libvma

## The same socket API, a different path through the network

VMA stands for NVIDIA Messaging Accelerator, and the repository is the source for it. The README describes it as a library that boosts performance for message based and streaming applications, giving the examples that matter: applications found in financial services market data environments, and Web2.0 clusters.

The mechanism is the interesting part. An application written over the standard socket API can run over Ethernet and/or InfiniBand from user space, with a full network stack bypass. The API the developer writes against does not change. What changes is where the work happens: the socket calls are serviced by a user space data path instead of the kernel network stack, which is what makes RDMA capable adaptors usable from ordinary code.

That is the whole design idea, and it is why the project is a library rather than a network stack of its own. An application that already uses sockets does not need an RDMA API rewritten into it. The project lists an Architecture page in its wiki as the place with additional information, which is where the real detail lives rather than in the README.

The homepage for the project is NVIDIA's own VMA product page under the Mellanox accelerator software range, which tells you how this is positioned: a vendor-accelerated performance product, not a general purpose networking library.

## Install and build documentation lives in the wiki, not the README

There is no build recipe in the README itself, and the project points elsewhere. Two wiki pages carry the installation information: a Downloads page that holds all download and installation information, and a Build-Instruction page for building VMA from source. The README's only additional pointers are the libvma README file, the VMA product page, and a suggestion to check out the rest of the wiki pages in the project.

That split matters for evaluation. The repository is the source, but the operational knowledge is hosted separately, so a reader has to leave the checkout to learn how to get a working installation. The README does not state a supported distribution list, a minimum kernel version, or a specific adaptor model, so those answers are not available from the repository text alone.

Support has two channels, both named in the README: opening a GitHub issue for questions, or contacting support@mellanox.com. The presence of a SECURITY.md file at the root, alongside a CHANGES file that records release notes, indicates that security reporting and change history are handled as separate documents from the source.

If you are assessing this project as a dependency, the practical first step is to open the wiki's Build-Instruction page, because the repository layout alone will not tell you whether the build will succeed on your distribution.

## An autotools build with a debian package alongside it

The repository layout is a classic GNU autotools project, and that tells you more about the build than the README does. At the root there is autogen.sh, configure.ac, Makefile.am and a config/ directory, which is the standard autotools arrangement where autogen.sh generates the configure script from configure.ac and the build itself is described in Makefile.am files. A .gittemplate and .gitignore are also present, along with the usual .github/ and a separate .ci/ directory for continuous integration configuration.

Next to that sit packaging and support directories. There is a debian/ directory, which means a Debian package definition is maintained in-tree, and a contrib/ directory for contributed or optional pieces. The code itself is in src/, with tests/ holding the test suites and tools/ holding command line utilities, and docs/ holding documentation.

The autotools choice is the practical point for an adopter. A project that still generates its configure script from configure.ac can be built on the distribution of your choice without pinning to a distribution package, and the in-tree debian/ directory gives you a starting point if you want to build your own package rather than use a vendor binary. The trade-off is a build that depends on the autotools toolchain being present and on a generated configure step, which is more moving parts than a plain make in a modern tree.

## Version 9.8.84 and a 2026 push, with the release notes in the tree

The versioning is a running series rather than semver. The listed releases are VMA 9.8.84 published on 2026-01-08, 9.8.83 on 2026-01-05 and 9.8.82 on 2025-12-24, three releases in the space of a couple of weeks. The last push to the master branch was on 2026-05-12.

The CHANGES file in the repository root is the changelog to read when deciding which build to take, and with patch releases arriving weekly in this period, the difference between two adjacent versions is likely to be small but real. That is the pattern of a library that is still being adjusted rather than one that has settled.

The badges tell you about the engineering process rather than the performance. There is a Coverity Scan build status badge, which points to static analysis being run as part of the build, and a GitHub version badge for release numbering. Neither is evidence about how fast the library is, and the README makes no throughput or latency claim to repeat.

The point to take away is that this is a vendor-maintained source tree with a support function behind it, a weekly patch cadence in early 2026, and development continuing after the last tagged release, since the push in May came after the January release.

## When VMA is the wrong tool

The scope condition is explicit in the project description: the library is for RDMA compatible network adaptors. If your hardware is a plain Ethernet card without RDMA support, or your application does not do message based or streaming I/O, there is nothing here to accelerate, and the bypass model buys nothing.

The second limitation is architectural rather than incidental. Bypassing the network stack means the work happens in user space, and the library is therefore not a drop-in performance switch. The README does not describe a configuration file, a runtime toggle, or a way to enable it per application, and it points to a separate Build-Instruction page rather than documenting the settings in the repository. If your team needs a change that can be switched on and off in production, that expectation needs checking against the wiki before you plan around it.

The third is the documentation footprint. The README is a short pointer document. Details about architecture, downloads and building live in a wiki, and the supported hardware combinations are not enumerated in the repository. That is workable for a team with a Mellanox support contact, and it is a poor fit for a team that wants to evaluate the library purely from the source.

There is also a licensing point to settle early, discussed below.

## The alternative is simply the kernel stack

The comparison worth making is not with another acceleration library but with the default. An application that uses ordinary TCP sockets and lets the kernel handle networking is portable, needs no special adaptor, and is available on every platform the team already supports. That path costs whatever the kernel's cost is.

VMA changes the trade by moving the data path into user space and putting an RDMA capable adaptor underneath it, which is exactly the point for market data feeds and cluster messaging where the per-message overhead dominates. The README's own framing, that the library lets applications written over the standard socket API run over Ethernet and/or InfiniBand with a full network stack bypass, is the argument: you keep the socket programming model and change the transport underneath.

So the decision is about whether your workload and your hardware justify the dependency, not about API novelty. If your code already works over sockets, adopting VMA is a packaging and platform decision rather than a rewrite. If it does not, or if you need to run on a machine with an ordinary network card, the kernel path remains the correct answer.

One practical caveat for mixed environments: since the acceleration is tied to specific adaptors, a fleet that includes both accelerated and unaccelerated machines needs a plan for the second group, and the README does not document a fallback mode.

## Reading the licence and the source layout for yourself

The repository root carries both a COPYING file and a LICENSE file, and the licence field GitHub shows for the repository is one it cannot classify. That combination usually means the terms are not a standard SPDX identifier, so the answer is in those files rather than in the metadata. Read both before you distribute anything built on this source, and note that a vendor library may carry additional clauses beyond the usual permissive text.

The rest of the tree rewards a look before you integrate. The src/ directory holds the implementation, tests/ the test suites, tools/ the command line utilities, contrib/ optional or contributed components, and docs/ the documentation. The presence of a dedicated tools/ directory suggests there is a way to exercise or inspect the library from a shell, which is useful for validating a build, but the README does not document those tools, so their interfaces have to be read from the source.

Taken together, the repository is a mature vendor source drop with in-tree packaging, a security policy, a changelog and a wiki for the operational detail, and it is aimed squarely at people who already run Mellanox RDMA hardware. That is a narrower audience than a general purpose networking library, and it is the right audience for a library whose entire value is moving socket traffic onto an RDMA adaptor without touching application code.

## Conclusion

Adopt VMA if you run message based or streaming workloads on RDMA capable Mellanox hardware and your application already speaks ordinary sockets, since the library exists precisely so that no application rewrite is needed to move traffic onto InfiniBand or Ethernet with the kernel stack bypassed. Do not adopt it for portable code, for a machine without a supported RDMA adaptor, or expecting a drop-in build with no configuration work, because the README routes installation through separate wiki pages rather than a documented quick start. Before you commit, read the Architecture and Build-Instruction wiki pages, confirm the adaptor and driver combination in the Download instructions, check the CHANGES file against the release you are picking, since the last listed release is 9.8.84 from 2026-01-08 while the last push was on 2026-05-12, and read the LICENSE and COPYING files yourself, because the licence field on the repository is one GitHub cannot classify.

## FAQ

### What is VMA and what does the libvma repository contain?

VMA is the NVIDIA Messaging Accelerator, a Linux user space library that lets applications written over the standard socket API run over Ethernet and/or InfiniBand with a full network stack bypass. The repository holds the source, with src/, tests/, tools/, contrib/, docs/ and a debian/ package definition at the root.

### How do I build or install VMA from libvma?

The README does not contain a build recipe. It points to the project wiki, where a Downloads page holds the download and installation information and a Build-Instruction page covers building VMA from source. The source tree itself uses autotools, with autogen.sh, configure.ac and Makefile.am at the root.

### What hardware does VMA require?

The project description states it is a Linux user space library for network socket acceleration based on RDMA compatible network adaptors, running over Ethernet and/or InfiniBand. The specific supported adaptors and drivers are not enumerated in the README, so the wiki Downloads page is the place to check them.

### Which VMA release should I use and how recent is the code?

The listed releases are 9.8.82 from 2025-12-24, 9.8.83 from 2026-01-05 and 9.8.84 from 2026-01-08, and the last push to master was on 2026-05-12. The CHANGES file in the repository root records what changed between versions.

### What licence does libvma use and how do I get support?

The repository contains both a COPYING file and a LICENSE file, while the licence field GitHub shows is one it cannot classify, so the terms are in those files. For support, the README asks you to open a GitHub issue or contact support@mellanox.com, and a SECURITY.md file covers security matters.

## Sources

- [Issues](https://github.com/Mellanox/libvma/issues)
- [Mellanox/libvma on GitHub](https://github.com/Mellanox/libvma)
- [Project website](https://www.mellanox.com/products/software/accelerator-software/vma?mtag=vma)
- [README](https://github.com/Mellanox/libvma/blob/master/README.md)
- [Releases](https://github.com/Mellanox/libvma/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mellanox-libvma