DAT_EP_POST_RDMA_WRITE(3DAT) | Direct Access Transport Library Functions | DAT_EP_POST_RDMA_WRITE(3DAT) |
dat_ep_post_rdma_write - write all data to the remote data buffer
cc [ flag... ] file... -ldat [ library... ] #include <dat/udat.h> DAT_RETURN
dat_ep_post_rdma_read (
IN DAT_EP_HANDLE ep_handle,
IN DAT_COUNT num_segments,
IN DAT_LMR_TRIPLET *local_iov,
IN DAT_DTO_COOKIE user_cookie,
IN DAT_RMR_TRIPLET *remote_buffer,
IN DAT_COMPLETION_FLAGS completion_flags
)
ep_handle
num_segments
local_iov
user_cookie
remote_buffer
completion_flags
Completion Suppression
0x01
Notification of Completion
0x04
Barrier Fence
0x08
The dat_ep_post_rdma_write() function requests the transfer of all the data specified by the local_iov over the connection of the ep_handle Endpoint into the remote_buffer.
The num_segments parameter specifies the number of segments in the local_iov. The local_iov segments are traversed in the I/O Vector order until all the data is transferred.
A Consumer must not modify the local_iov or its content until the DTO is completed. When a Consumer does not adhere to this rule, the behavior of the Provider and the underlying Transport is not defined. Providers that allow Consumers to get ownership of the local_iov but not the memory it specifies back after the dat_ep_post_rdma_write() returns should document this behavior and also specify its support in Provider attributes. This behavior allows Consumers full control of the local_iov after dat_ep_post_rdma_write() returns. Because this behavior is not guaranteed by all Providers, portable Consumers should not rely on this behavior. Consumers should not rely on the Provider copying local_iov information.
The DAT_SUCCESS return of the dat_ep_post_rdma_write() is at least the equivalent of posting an RDMA Write operation directly by native Transport. Providers should avoid resource allocation as part of dat_ep_post_rdma_write() to ensure that this operation is nonblocking and thread safe for an UpCall.
The completion of the posted RDMA Write is reported to the Consumer asynchronously through a DTO Completion event based on the specified completion_flags value. The value of DAT_COMPLETION_UNSIGNALLED_FLAG is only valid if the Endpoint Request Completion Flags DAT_COMPLETION_UNSIGNALLED_FLAG. Otherwise, DAT_INVALID_PARAMETER is returned.
The user_cookie allows Consumers to have unique identifiers for each DTO. These identifiers are completely under user control and are opaque to the Provider. There is no requirement on the Consumer that the value user_cookie should be unique for each DTO. The user_cookie is returned to the Consumer in the Completion event for the posted RDMA Write.
The operation is valid for the Endpoint in the DAT_EP_STATE_CONNECTED and DAT_EP_STATE_DISCONNECTED states. If the operation returns successfully for the Endpoint in the DAT_EP_STATE_DISCONNECTED state, the posted RDMA Write is immediately flushed to request_evd_handle.
DAT_SUCCESS
DAT_INSUFFICIENT_RESOURCES
DAT_INVALID_PARAMETER
DAT_INVALID_HANDLE
DAT_INVALID_STATE
DAT_LENGTH_ERROR
DAT_PROTECTION_VIOLATION
DAT_PRIVILEGES_VIOLATION
For best RDMA Write operation performance, the Consumer should align each buffer segment of local_iov to the Optimal Buffer Alignment attribute of the Provider. For portable applications, the Consumer should align each buffer segment of local_iov to the DAT_OPTIMAL_ALIGNMENT.
See attributes(7) for descriptions of the following attributes:
ATTRIBUTE TYPE | ATTRIBUTE VALUE |
Interface Stability | Standard: uDAPL, 1.1, 1.2 |
MT-Level | Unsafe |
July 16, 2004 | OmniOS |