fi_provider(7)

🌸 fi_provider(7): Fabric Interface Providers 🌸

okay bestie, welcome to fi_provider(7) from Libfabric v2.5.1 — the manual page all about Fabric Interface Providers. This is the page that explains how providers slot into the libfabric universe, and honestly? It's giving architecture, it's giving debugging, it's giving “your app is gonna talk to hardware and I'm gonna make it make sense.” 💅

---

✨ NAME ✨

fi_provider — Fabric Interface Providers. That's the whole name, no cap. 🫶

✨ OVERVIEW ✨

First things first: go peek at fi_arch(7) for a quick lil description of how providers fit into the libfabric architecture. It's the lore, okay? 📚

Conceptually, a fabric provider implements and maps the libfabric API over lower-level network software and/or hardware. Most application calls into the libfabric API go directly into a provider’s implementation of that API. So yeah, the provider is lowkey doing the actual mapping work. 💪

Libfabric providers are grouped into different type: core, utility, hooking, and offload. (Yes, “type” — we keep it exactly like that, it's iconic.) These are described in more detail below. The following diagram illustrates the architecture between the provider types:

       ---------------------------- libfabric API ----------------------------
         [core]   provider|<- [hooking provider]
       [services]   API   |  --- libfabric API ---
                          |<- [utility provider]
                          |  ---------------- libfabric API ------------------
                          |<-  [core provider] <-peer API-> [offload provider]

All providers plug into libfabric using an exported provider API. libfabric supports both internal providers, which ship with the library for user convenience, as well as external providers. External provider libraries must be in the library search path, end with the suffix -fi, and export the function fi_prov_ini(). Write that down. 🗒️

Once registered with the libfabric core, a provider will be reported to applications as part of the discovery process. Hooking and utility providers will intercept libfabric calls from the application to perform some task before calling through to the next provider. If there’s no need to intercept a specific API call, the application will call directly to the core provider. Where possible, provider-to-provider communication is done using the libfabric APIs itself, including the use of provider specific extensions to reduce call overhead. Efficient and cute. ✨

libfabric defines a set of APIs that specifically target providers that may be used as peers. These APIs are oddly enough called peer APIs. Peer APIs are technically part of the external libfabric API, but are not designed for direct use by applications and are not considered stable for API backwards compatibility. So like, not for casual app-dev consumption, bestie. ⚠️

👑 Core Providers 👑

Core providers are stand-alone providers that usually target a specific class of networking devices. That is, a specific NIC, class of network hardware, or lower-level software interface. The core providers are usually what most application developers are concerned with. Core providers may only support libfabric features and interfaces that map efficiently to the underlying hardware or network protocols. They're the main character energy of the provider world. 🌟

The following core providers are built into libfabric by default, assuming all build pre-requisites are met. That is, necessary libraries are installed, operating system support is available, etc. This list is not exhaustive. So if your fave isn't here, don't panic — it's just not an exhaustive list. 🫶

• CXI — Provider for Cray’s Slingshot network. See fi_cxi(7) for more information. 🌈
• EFA — A provider for the Amazon EC2 Elastic Fabric Adapter (EFA) (https://aws.amazon.com/hpc/efa/), a custom-built OS bypass hardware interface for inter-instance communication on EC2. See fi_efa(7) for more information. ☁️
• LPP — A provider runs on FabreX PCIe networks. See fi_lpp(7) for more information. 🚀
• OPX — Supports Omni-Path networking from Cornelis Networks. See fi_opx(7) for more information. 🧡
• PSM2 — Older provider for Omni-Path networks. See fi_psm2(7) for more information. 👵
• PSM3 — Provider for Ethernet networking from Intel. See fi_psm3(7) for more information. 🌐
• SHM — A provider for intra-node communication using shared memory. See fi_shm(7) for more information. 🧠
• TCP — A provider which runs over the TCP/IP protocol and is available on multiple operating systems. This provider enables develop of libfabric applications on most platforms. See fi_tcp(7) for more information. 🐢
• UCX — A provider which runs over the UCX library which is currently supported by Infiniband fabrics from NVIDIA. See fi_ucx(7) for more information. 💚
• UDP — A provider which runs over the UDP/IP protocol and is available on multiple operating systems. This provider enables develop of libfabric applications on most platforms. See fi_udp(7) for more information. 📨
• Verbs — This provider targets RDMA NICs for both Linux and Windows platforms. See fi_verbs(7) for more information. 🪟

🧚 Utility Providers 🧚

Utility providers are named with a starting prefix of ofi_. Utility providers are distinct from core providers in that they are not associated with specific classes of devices. They instead work with core providers to expand their features and interact with core providers through libfabric interfaces internally. Utility providers are used to support a specific endpoint type over a simpler endpoint type. So they're like the little helper besties that make the core providers do more. 🫶

Utility providers show up as part of the return’s provider’s name. See fi_fabric(3). Utility providers are enabled automatically for core providers that do not support the feature set requested by an application. Automatic glow-up, basically. ✨

• RxM — Implements RDM endpoint semantics over MSG endpoints. See fi_rxm(7) for more information. 🎀
• RxD — Implements RDM endpoint semantis over DGRAM endpoints. See fi_rxd(7) for more information. 🦋

💅 Hooking Providers 💅

Hooking providers are mostly used for debugging purposes. Since hooking providers are built and included in release versions of libfabric, they are always available and have no impact on performance unless enabled. Hooking providers can layer over all other providers and intercept, or hook, their calls in order to perform some dedicated task, such as gathering performance data on call paths or providing debug output. So they're like little spies, but make it debug. 🕵️‍♀️

See fi_hook(7) for more information. 👀

🚀 Offload Providers 🚀

Offload providers start with the naming prefix off_. An offload provider is meant to be paired with other core and/or utility providers. An offload provider is intended to accelerate specific types of communication, generally by taking advantage of network services that have been offloaded into hardware, though actual hardware offload support is not a requirement. Hardware acceleration vibes, but make it optional. ⚡

🔗 LINKx (LNX) provider 🔗

The LNX provider is designed to link two or more providers, allowing applications to seamlessly use multiple providers or NICs. This provider uses the libfabric peer infrastructure to aid in the use of the underlying providers. This version of the provider is able to link any libfabric provider which supports the FI_PEER capability. Linking providers like it's a group chat, honestly. 👯‍♀️

See fi_lnx(7) for more information. 🫶

🌟 SEE ALSO 🌟

fabric(7) fi_provider(3) — go read those too, bestie. 📚

🫶 AUTHORS 🫶

OpenFabrics. periodt. 💅

💖 signed, sealed, delivered by the Libfabric Programmer’s Manual, 2025-06-07 — Libfabric v2.5.1. mwah! 💖