2 .\" This manual page is derived from the DAT/uDAPL 1.2 specification.
3 .\" Portions Copyright (c) 2007, Sun Microsystems, Inc. All Rights Reserved.
4 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
5 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
6 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
7 .TH DAT_EP_CREATE_WITH_SRQ 3DAT "Jul 16, 2004"
9 dat_ep_create_with_srq \- create an instance of End Point with Shared Receive
14 cc [ \fIflag\fR\&.\|.\|. ] \fIfile\fR\&.\|.\|. \fB-ldat\fR [ \fIlibrary\fR\&.\|.\|. ]
15 #include <\fBdat/udat.h\fR>
18 dat_ep_create_with_srq (
19 IN DAT_IA_HANDLE ia_handle,
20 IN DAT_PZ_HANDLE pz_handle,
21 IN DAT_EVD_HANDLE recv_evd_handle,
22 IN DAT_EVD_HANDLE request_evd_handle,
23 IN DAT_EVD_HANDLE connect_evd_handle,
24 IN DAT_SRQ_HANDLE srq_handle,
25 IN DAT_EP_ATTR *ep_attributes,
26 OUT DAT_EP_HANDLE *ep_handle
37 Handle for an open instance of the IA to which the created Endpoint belongs.
46 Handle for an instance of the Protection Zone.
52 \fB\fIrecv_evd_handle\fR\fR
55 Handle for the Event Dispatcher where events for completions of incoming
56 (receive) DTOs are reported. \fBDAT_HANDLE_NULL\fR specifies that the Consumer
57 is not interested in events for completions of receives.
63 \fB\fIrequest_evd_handle\fR\fR
66 Handle for the Event Dispatcher where events for completions of outgoing (Send,
67 RDMA Write, RDMA Read, and RMR Bind) DTOs are reported. \fBDAT_HANDLE_NULL\fR
68 specifies that the Consumer is not interested in events for completions of
75 \fB\fIconnect_evd_handle\fR\fR
78 Handle for the Event Dispatcher where Connection events are reported.
79 \fBDAT_HANDLE_NULL\fR specifies that the Consumer is not interested in
80 connection events for now.
86 \fB\fIsrq_handle\fR\fR
89 Handle for an instance of the Shared Receive Queue.
95 \fB\fIep_attributes\fR\fR
98 Pointer to a structure that contains Consumer-requested Endpoint attributes.
105 \fB\fIep_handle\fR\fR
108 Handle for the created instance of an Endpoint.
114 The \fBdat_ep_create_with_srq()\fR function creates an instance of an Endpoint
115 that is using SRQ for Recv buffers is provided to the Consumer as
116 \fIep_handle\fR. The value of \fIep_handle\fR is not defined if the
117 \fBDAT_RETURN\fR is not \fBDAT_SUCCESS\fR.
120 The Endpoint is created in the Unconnected state.
123 Protection Zone \fIpz_handle\fR allows Consumers to control what local memory
124 the Endpoint can access for DTOs except Recv and what memory remote RDMA
125 operations can access over the connection of a created Endpoint. Only memory
126 referred to by LMRs and RMRs that match the Endpoint Protection Zone can be
127 accessed by the Endpoint. The Recv DTO buffers PZ must match the SRQ PZ. The
128 SRQ PZ might or might not be the same as the EP one. Check Provider attribute
129 for the support of different PZs between SRQ and its EPs.
132 The \fIrecv_evd_handle\fR and \fIrequest_evd_handle\fR arguments are Event
133 Dispatcher instances where the Consumer collects completion notifications of
134 DTOs. Completions of Receive DTOs are reported in \fIrecv_evd_handle\fR Event
135 Dispatcher, and completions of Send, RDMA Read, and RDMA Write DTOs are
136 reported in \fIrequest_evd_handle\fR Event Dispatcher. All completion
137 notifications of RMR bindings are reported to a Consumer in
138 \fIrequest_evd_handle\fR Event Dispatcher.
141 All Connection events for the connected Endpoint are reported to the Consumer
142 through \fIconnect_evd_handle\fR Event Dispatcher.
145 Shared Receive Queue \fIsrq_handle\fR specifies where the EP will dequeue Recv
149 The created EP can be reset. The relationship between SRQ and EP is not
150 effected by \fBdat_ep_reset\fR(3DAT).
153 SRQ can not be disassociated or replaced from created EP. The only way to
154 disassociate SRQ from EP is to destroy EP.
157 Receive buffers cannot be posted to the created Endpoint. Receive buffers must
158 be posted to the SRQ to be used for the created Endpoint.
161 The ep_attributes parameter specifies the initial attributes of the created
162 Endpoint. Consumer can not specify \fINULL\fR for \fIep_attributes\fR but can
163 specify values only for the parameters needed and default for the rest.
166 For \fImax_request_dtos\fR and \fImax_request_iov\fR, the created Endpoint will
167 have at least the Consumer requested values but might have larger values.
168 Consumer can query the created Endpoint to find out the actual values for these
169 attributes. Created Endpoint has the exact Consumer requested values for
170 \fImax_recv_dtos\fR, \fImax_message_size\fR, \fImax_rdma_size\fR, \fImax_
171 rdma_read_in\fR, and \fImax_rdma_read_out\fR. For all other attributes, except
172 \fImax_recv_iov\fR that is ignored, the created Endpoint has the exact values
173 requested by Consumer. If Provider cannot satisfy the Consumer requested
174 attribute values the operation fails.
179 \fB\fBDAT_SUCCESS\fR\fR
182 The operation was successful.
188 \fB\fBDAT_INSUFFICIENT_RESOURCES\fR\fR
191 The operation failed due to resource limitations.
197 \fB\fBDAT_INVALID_HANDLE\fR\fR
206 \fB\fBDAT_INVALID_PARAMETER\fR\fR
209 Invalid parameter. One of the requested EP parameters or attributes was invalid
210 or a combination of attributes or parameters is invalid. For example,
211 \fIpz_handle\fR specified does not match the one for SRQ or the requested
212 maximum RDMA Read IOV exceeds IA capabilities..
218 \fB\fBDAT_MODEL_NOT_SUPPORTED\fR\fR
221 The requested Provider Model was not supported.
227 The Consumer creates an Endpoint prior to the establishment of a connection.
228 The created Endpoint is in \fBDAT_EP_STATE_UNCONNECTED\fR. Consumers can do the
233 Request a connection on the Endpoint through \fBdat_ep_connect\fR(3DAT) or
234 \fBdat_ep_dup_connect\fR(3DAT) for the active side of the connection model.
239 Associate the Endpoint with the Pending Connection Request that does not
240 have an associated local Endpoint for accepting the Pending Connection Request
241 for the passive/server side of the con-nection model.
246 Create a Reserved Service Point with the Endpoint for the passive/server
247 side of the connection model. Upon arrival of a Connection Request on the
248 Service Point, the Consumer accepts the Pending Connection Request that has the
249 Endpoint associated with it.
253 The Consumer cannot specify a \fIrequest_evd_handle\fR (\fIrecv_evd_handle\fR)
254 with Request Completion Flags (Recv Completion Flags) that do not match the
255 other Endpoint Completion Flags for the DTO/RMR completion streams that use the
256 same EVD. If \fIrequest_evd_handle\fR (\fIrecv_evd_ handle\fR) is used for
257 request (recv) completions of an Endpoint whose associated Request (Recv)
258 Completion Flag attribute is \fBDAT_COMPLETION_UNSIGNALLED_FLAG\fR, the Request
259 Completion Flags and Recv Completion Flags for all Endpoint completion streams
260 that use the EVD must specify the same. By definition, completions of all Recv
261 DTO posted to SRQ complete with Signal. Analogously, if \fIrecv_evd_handle\fR
262 is used for recv completions of an Endpoint whose associated Recv Completion
263 Flag attribute is \fBDAT_COMPLETION_SOLICITED_WAIT\fR, the Recv Completion
264 Flags for all Endpoint Recv completion streams that use the same EVD must
265 specify the same Recv Completion Flags attribute value and the EVD cannot be
266 used for any other event stream types. If \fIrecv_evd_handle\fR is used for
267 Recv completions of an Endpoint that uses SRQ and whose Recv Completion Flag
268 attribute is \fBDAT_COMPLETION_EVD_THRESHOLD\fR then all Endpoint DTO
269 completion streams (request and/or recv completion streams) that use that
270 \fIrecv_evd_handle\fR must specify \fBDAT_COMPLETION_EVD_THRESHOLD\fR. Other
271 event stream types can also use the same EVD.
274 Consumers might want to use \fBDAT_COMPLETION_UNSIGNALLED_FLAG\fR for Request
275 and/or Recv completions when they control locally with posted DTO/RMR
276 completion flag (not needed for Recv posted to SRQ) whether posted DTO/RMR
277 completes with Signal or not. Consumers might want to use
278 \fBDAT_COMPLETION_SOLICITED_WAIT\fR for Recv completions when the remote sender
279 side control whether posted Recv competes with Signal or not or not. uDAPL
280 Consumers might want to use \fBDAT_COMPLETION_EVD_THRESHOLD\fR for Request
281 and/or Recv completions when they control waiter unblocking with the
282 \fIthreshold\fR parameter of the \fBdat_evd_wait\fR(3DAT).
285 Some Providers might restrict whether multiple EPs that share a SRQ can have
286 different Protection Zones. Check the \fIsrq_ep_pz_difference_support\fR
287 Provider attribute for it.
290 Consumers might want to have a different PZ between EP and SRQ. This allows
291 incoming RDMA operations to be specific to this EP PZ and not the same for all
292 EPs that share SRQ. This is critical for servers that supports multiple
296 The Provider is strongly encouraged to create an EP that is ready to be
297 connected. Any effects of previous connections or connection establishment
298 attempts on the underlying Transport-specific Endpoint to which the DAT
299 Endpoint is mapped to should be hidden from the Consumer. The methods described
305 The Provider does not create an underlying Transport Endpoint until the
306 Consumer is connecting the Endpoint or accepting a connection request on it.
307 This allows the Provider to accumulate Consumer requests for attribute settings
308 even for attributes that the underlying transport does not allow to change
309 after the Transport Endpoint is created.
315 The Provider creates the underlying Transport Endpoint or chooses one from a
316 pool of Provider-controlled Transport Endpoints when the Consumer creates the
317 Endpoint. The Provider chooses the Transport Endpoint that is free from any
318 underlying internal attributes that might prevent the Endpoint from being
319 connected. For IB and IP, that means that the Endpoint is not in the TimeWait
320 state. Changing of some of the Endpoint attributes becomes hard and might
321 potentially require mapping the Endpoint to another underlying Transport
322 Endpoint that might not be feasible for all transports.
328 The Provider allocates a Transport-specific Endpoint without worrying about
329 impact on it from previous connections or connection establishment attempts.
330 Hide the Transport-specific TimeWait state or CM timeout of the underlying
331 transport Endpoint within \fBdat_ep_connect\fR(3DAT),
332 \fBdat_ep_dup_connect\fR(3DAT), or \fBdat_cr_accept\fR(3DAT). On the Active
333 side of the connection establishment, if the remnants of a previous connection
334 for Transport-specific Endpoint can be hidden within the Timeout parameter, do
335 so. If not, generating \fBDAT_CONNECTION_ EVENT_NON_PEER_REJECTED\fR is an
336 option. For the Passive side, generating a
337 \fBDAT_CONNECTION_COMPLETION_ERROR\fR event locally, while sending a
338 non-peer-reject message to the active side, is a way of handling it.
342 Any transitions of an Endpoint into an Unconnected state can be handled
343 similarly. One transition from a Disconnected to an Unconnected state is a
347 For \fBdat_ep_reset\fR(3DAT), the Provider can hide any remnants of the
348 previous connection or failed connection establishment in the operation itself.
349 Because the operation is synchronous, the Provider can block in it until the
350 TimeWait state effect of the previous connection or connection setup is
351 expired, or until the Connection Manager timeout of an unsuccessful connection
352 establishment attempt is expired. Alternatively, the Provider can create a new
353 Endpoint for the Consumer that uses the same handle.
356 DAT Providers are required not to change any Consumer-specified Endpoint
357 attributes during connection establishment. If the Consumer does not specify an
358 attribute, the Provider can set it to its own default. Some EP attributes,
359 like outstanding RDMA Read incoming or outgoing, if not set up by the Consumer,
360 can be changed by Providers to establish connection. It is recommended that the
361 Provider pick the default for outstanding RDMA Read attributes as 0 if the
362 Consumer has not specified them. This ensures that connection establishment
363 does not fail due to insufficient outstanding RDMA Read resources, which is a
364 requirement for the Provider.
367 The Provider is not required to check for a mismatch between the maximum RDMA
368 Read IOV and maximum RDMA Read outgoing attributes, but is allowed to do so. In
369 the later case it is allowed to return \fBDAT_INVALID_ PARAMETER\fR when a
370 mismatch is detected. Provider must allocate resources to satisfy the
371 combination of these two EP attributes for local RDMA Read DTOs.
375 See \fBattributes\fR(5) for descriptions of the following attributes:
383 ATTRIBUTE TYPE ATTRIBUTE VALUE
385 Interface Stability Standard: uDAPL, 1.2
393 \fBdat_ep_create\fR(3DAT), \fBdat_srq_create\fR(3DAT),
394 \fBdat_srq_free\fR(3DAT), \fBdat_srq_query\fR(3DAT), \fBlibdat\fR(3LIB),