+The Remote Direct Memory Access (RDMA) infrastructure provides high-performance interconnect between computing and storage nodes.
+It can operate over different physical networks, for instance Ethernet and Infiniband.
+
+The implementation of the RDMA stack consists of several components.
+There is the core kernel infrastructure, and drivers for Host Channel Adapters (HCAs), providing access to the kernel verbs.
+Userspace applications never interact with the kernel devices directly, the core libibverbs library and vendor-specific userspace drivers provide unified and device-specific verbs.
+
+Since RDMA intent of providing low-latency low-overhead operations, performant HCAs offload a lot of operations from CPU.
+Also, typical in-line operations like send and receive can be initiated and completed in userspace, where kernel only assists in the connection establishment and teardown.
+Due to this, the userspace RDMA software stack is crusial for its operations.
+
+FreeBSD base system includes port of the so called OFED kernel core component, kernel drivers, as well as userspace core (libibverbs) and userspace drivers, for instance libmlx5 for managing Nvidia Connect-X4 and later HCAs.
+Over time, the kernel parts get some significant updates from the infiniband code in the Linux kernel, which become the home for updated OFED.
+Userspace part of OFED was converted into the rdma-core userspace project, that only supports Linux (and glibc).
+Since userspace drivers in rdma-core provide essential functionality, and since FreeBSD userspace RDMA components are quite outdated, the situation overall needs a resolution.
+
+We attemtpted to update the in-tree userspace components by importing the series of rdma-core commits with dependencies, but it quickly proved to be not feasible.
+Instead we started looking at what it would take to make rdma-core compile and run on FreeBSD.
+
+First, there were bunch of missed glibc-specific APIs that were used in rdma-core, for instance, strdupa() and friends, tdestroy(3), some pthread functions.
+These were easy to handle in the base system, and addition of them benefited the whole FreeBSD porting story.
+
+Next, and more serious, the unportable features of glibc were used everywhere in the sources, and trying to cover them all would cause huge porting patch, which is problematic to push upstream, even for cooperating upstream.
+Instead, the idea of using an approach similar to LinuxKPI for kernel code, was formed and developed, called LinuxAPI.
+Unlike LinuxKPI, which handles architectural mismatches between Linux kernel and FreeBSD kernel, in addition to the different C interfaces, LinuxAPI needs to smoother the differences around extensions to the same core functionality defined by POSIX.
+It is mostly about bits that are not defined by POSIX but needed for RDMA to function, like networking interface enumeration, or discovery of the rdma-capable devices and their capabilities etc.
+
+It seems that people consider the LinuxAPI useful outside the rdma-core porting efforts already, there is a project github.com/freebsd/linuxapi which takes the developed set of headers and extends it further.
+We are currently working on providing the permissive license to make the library useful without additional strings attached.
+
+Our initial goal, also limited by the available hardware, is to have rdma-core work with the ConnectX-4 cards.
+Of course we welcome all vendors interested in RDMA on FreeBSD to improve the port to properly support their cards.
+
+The result of the porting is available as the repository.
+Also we try to upstream the changes so that FreeBSD would become the second natively supported platform for rdma-core.
+The Pull Request to the github project is submitted.
+There is currently a blocking discussion about the way to organize CI for FreeBSD port.