1fi_provider(7)                 Libfabric v1.7.0                 fi_provider(7)
2
3
4

NAME

6       fi_provider - Fabric Interface Providers
7

OVERVIEW

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

CORE VERSUS UTILITY PROVIDERS

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

PROVIDER REQUIREMENTS

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

LOGGING INTERFACE

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

SEE ALSO

206       fi_gni(7),    fi_hook(7),    fi_psm(7),   fi_sockets(7),   fi_usnic(7),
207       fi_verbs(7), fi_bgq(7),
208

AUTHORS

210       OpenFabrics.
211
212
213
214Libfabric Programmer's Manual     2018-10-05                    fi_provider(7)
Impressum