1fi_provider(7) Libfabric v1.7.0 fi_provider(7)
2
3
4
6 fi_provider - Fabric Interface Providers
7
9 Conceptually, a fabric provider may be viewed as a local hardware NIC
10 driver, though a provider is not limited by this definition. The first
11 component of libfabric is a general purpose framework that is capable
12 of handling different types of fabric hardware. All fabric hardware
13 devices and their software drivers are required to support this frame‐
14 work. Devices and the drivers that plug into the libfabric framework
15 are referred to as fabric providers, or simply providers.
16
17 This distribution of libfabric contains the following providers (al‐
18 though more may be available via run-time plug-ins):
19
20 Core providers
21 GNI A provider for the Aries interconnect in Cray XC(TM) systems
22 utilizing the user-space Generic Networking Interface. See
23 fi_gni(7) for more information.
24
25 PSM High-speed InfiniBand networking from Intel. See fi_psm(7) for
26 more information.
27
28 Sockets
29 A general purpose provider that can be used on any network that
30 supports TCP/UDP sockets. This provider is not intended to pro‐
31 vide performance improvements over regular TCP/UDP sockets, but
32 rather to allow developers to write, test, and debug application
33 code even on platforms that do not have high-speed networking.
34 See fi_sockets(7) for more information.
35
36 usNIC Ultra low latency Ethernet networking over Cisco userspace VIC
37 adapters. See fi_usnic(7) for more information.
38
39 Verbs This provider uses the Linux Verbs API for network transport.
40 Application performance is, obviously expected to be similar to
41 that of the native Linux Verbs API. Analogous to the Sockets
42 provider, the Verbs provider is intended to enable developers to
43 write, test, and debug application code on platforms that only
44 have Linux Verbs-based networking. See fi_verbs(7) for more in‐
45 formation.
46
47 Blue Gene/Q
48 See fi_bgq(7) for more information.
49
50 Utility providers
51 RxM The RxM provider (ofi_rxm) is an utility provider that supports
52 RDM endpoints emulated over MSG endpoints of a core provider.
53 See fi_rxm(7) for more information.
54
55 Special providers
56 Hook The hook provider is a special type of provider that can layer
57 over any other provider, unless FI_FABRIC_DIRECT is used. The
58 hook provider is always available, but has no impact unless en‐
59 abled. When enabled, the hook provider will intercept all calls
60 to the underlying core or utility provider(s). The hook
61 provider is useful for capturing performance data or providing
62 debugging information, even in release builds of the library.
63 See fi_hook(7) for more information.
64
66 Core providers implement the libfabric interfaces directly over
67 low-level hardware and software interfaces. They are designed to sup‐
68 port a specific class of hardware, and may be limited to supporting a
69 single NIC. Core providers often only support libfabric features and
70 interfaces that map efficiently to their underlying hardware.
71
72 Utility providers are distinct from core providers in that they are not
73 associated with specific classes of devices. They instead work with
74 core providers to expand their features, and interact with core
75 providers through libfabric interfaces internally. Utility providers
76 are often used to support a specific endpoint type over a simpler end‐
77 point type. For example, the RXD provider implements reliability over
78 unreliable datagram endpoints. The utility providers will not layer
79 over the sockets provider unless it is explicitly requested.
80
81 Utility providers show up as a component in the core provider's compo‐
82 nent list. See fi_fabric(3). Utility providers are enabled automati‐
83 cally for core providers that do not support the feature set requested
84 by an application.
85
87 Libfabric provides a general framework for supporting multiple types of
88 fabric objects and their related interfaces. Fabric providers have a
89 large amount of flexibility in selecting which components they are able
90 and willing to support, based on specific hardware constraints.
91 Provider developers should refer to docs/provider for information on
92 functionality supplied by the framework to assist in provider implemen‐
93 tation. To assist in the development of applications, libfabric speci‐
94 fies the following requirements that must be met by any fabric
95 provider, if requested by an application.
96
97 Note that the instantiation of a specific fabric object is subject to
98 application configuration parameters and need not meet these require‐
99 ments.
100
101 · A fabric provider must support at least one endpoint type.
102
103 · All endpoints must support the message queue data transfer interface
104 (fi_ops_msg).
105
106 · An endpoint that advertises support for a specific endpoint capabili‐
107 ty must support the corresponding data transfer interface.
108
109 · FI_ATOMIC - fi_ops_atomic
110
111 · FI_RMA - fi_ops_rma
112
113 · FI_TAGGED - fi_ops_tagged
114
115 · Endpoints must support all transmit and receive operations for any
116 data transfer interface that they support.
117
118 · Exception: If an operation is only usable for an operation that the
119 provider does not support, and support for that operation is conveyed
120 using some other mechanism, the operation may return
121
122 · FI_ENOSYS. For example, if the provider does not support injected
123 data, it can set the attribute inject_size = 0, and fail all fi_in‐
124 ject operations.
125
126 · The framework supplies wrappers around the 'msg' operations that can
127 be used. For example, the framework implements the sendv() msg oper‐
128 ation by calling sendmsg(). Providers may reference the general op‐
129 eration, and supply on the sendmsg() implementation.
130
131 · Providers must set all operations to an implementation. Function
132 pointers may not be left NULL or uninitialized. The framework sup‐
133 plies empty functions that return -FI_ENOSYS which can be used for
134 this purpose.
135
136 · Endpoints must support the CM interface as follows:
137
138 · FI_EP_MSG endpoints must support all CM operations.
139
140 · FI_EP_DGRAM endpoints must support CM getname and setname.
141
142 · FI_EP_RDM endpoints must support CM getname and setname.
143
144 · Providers that support connectionless endpoints must support all AV
145 operations (fi_ops_av).
146
147 · Providers that support memory registration, must support all MR oper‐
148 ations (fi_ops_mr).
149
150 · Providers should support both completion queues and counters.
151
152 · If FI_RMA_EVENT is not supported, counter support is limited to local
153 events only.
154
155 · Completion queues must support the FI_CQ_FORMAT_CONTEXT and
156 FI_CQ_FORMAT_MSG.
157
158 · Providers that support FI_REMOTE_CQ_DATA shall support FI_CQ_FOR‐
159 MAT_DATA.
160
161 · Providers that support FI_TAGGED shall support FI_CQ_FORMAT_TAGGED.
162
163 · A provider is expected to be forward compatible, and must be able to
164 be compiled against expanded fi_xxx_ops structures that define new
165 functions added after the provider was written. Any unknown func‐
166 tions must be set to NULL.
167
168 · Providers shall document in their man page which features they sup‐
169 port, and any missing requirements.
170
171 Future versions of libfabric will automatically enable a more complete
172 set of features for providers that focus their implementation on a nar‐
173 row subset of libfabric capabilities.
174
176 Logging is performed using the FI_ERR, FI_LOG, and FI_DEBUG macros.
177
178 DEFINITIONS
179 #define FI_ERR(prov_name, subsystem, ...)
180
181 #define FI_LOG(prov_name, prov, level, subsystem, ...)
182
183 #define FI_DEBUG(prov_name, subsystem, ...)
184
185 ARGUMENTS
186 prov_name
187 String representing the provider name.
188
189 prov Provider context structure.
190
191 level Log level associated with log statement.
192
193 subsystem
194 Subsystem being logged from.
195
196 DESCRIPTION
197 FI_ERR Always logged.
198
199 FI_LOG Logged if the intended provider, log level, and subsystem param‐
200 eters match the user supplied values.
201
202 FI_DEBUG
203 Logged if configured with the --enable-debug flag.
204
206 fi_gni(7), fi_hook(7), fi_psm(7), fi_sockets(7), fi_usnic(7),
207 fi_verbs(7), fi_bgq(7),
208
210 OpenFabrics.
211
212
213
214Libfabric Programmer's Manual 2018-10-05 fi_provider(7)