Provided by: libfabric-dev_1.5.3-1_amd64 bug

NAME

       fi_msg - Message data transfer operations

       fi_recv / fi_recvv / fi_recvmsg
              Post a buffer to receive an incoming message

       fi_send / fi_sendv / fi_sendmsg
       fi_inject / fi_senddata : Initiate an operation to send a message

SYNOPSIS

              #include <rdma/fi_endpoint.h>

              ssize_t fi_recv(struct fid_ep *ep, void * buf, size_t len,
                  void *desc, fi_addr_t src_addr, void *context);

              ssize_t fi_recvv(struct fid_ep *ep, const struct iovec *iov, void **desc,
                  size_t count, fi_addr_t src_addr, void *context);

              ssize_t fi_recvmsg(struct fid_ep *ep, const struct fi_msg *msg,
                  uint64_t flags);

              ssize_t fi_send(struct fid_ep *ep, void *buf, size_t len,
                  void *desc, fi_addr_t dest_addr, void *context);

              ssize_t fi_sendv(struct fid_ep *ep, const struct iovec *iov,
                  void **desc, size_t count, fi_addr_t dest_addr, void *context);

              ssize_t fi_sendmsg(struct fid_ep *ep, const struct fi_msg *msg,
                  uint64_t flags);

              ssize_t fi_inject(struct fid_ep *ep, void *buf, size_t len,
                  fi_addr_t dest_addr);

              ssize_t fi_senddata(struct fid_ep *ep, void *buf, size_t len,
                  void *desc, uint64_t data, fi_addr_t dest_addr, void *context);

              ssize_t fi_injectdata(struct fid_ep *ep, void *buf, size_t len,
                  uint64_t data, fi_addr_t dest_addr);

ARGUMENTS

       ep : Fabric endpoint on which to initiate send or post receive buffer.

       buf : Data buffer to send or receive.

       len  :  Length of data buffer to send or receive, specified in bytes.  Valid transfers are
       from 0 bytes up to the endpoint's max_msg_size.

       iov : Vectored data buffer.

       count : Count of vectored data entries.

       desc : Descriptor associated with the data buffer

       data : Remote CQ data to transfer with the sent message.

       dest_addr : Destination address  for  connectionless  transfers.   Ignored  for  connected
       endpoints.

       src_addr  :  Source address to receive from for connectionless transfers.  Applies only to
       connectionless endpoints with the  FI_DIRECTED_RECV  capability  enabled,  otherwise  this
       field is ignored.  If set to FI_ADDR_UNSPEC, any source address may match.

       msg : Message descriptor for send and receive operations.

       flags : Additional flags to apply for the send or receive operation.

       context : User specified pointer to associate with the operation.

DESCRIPTION

       The  send  functions  --  fi_send, fi_sendv, fi_sendmsg, fi_inject, and fi_senddata -- are
       used to transmit a message from one endpoint to another  endpoint.   The  main  difference
       between  send  functions  are the number and type of parameters that they accept as input.
       Otherwise, they perform the same general function.  Messages sent using fi_msg  operations
       are received by a remote endpoint into a buffer posted to receive such messages.

       The  receive  functions  --  fi_recv,  fi_recvv,  fi_recvmsg  --  post a data buffer to an
       endpoint to receive inbound messages.  Similar to the send operations, receive  operations
       operate  asynchronously.   Users  should  not  touch  the  posted data buffer(s) until the
       receive operation has completed.

       An endpoint must be enabled before an application can post send or receive  operations  to
       it.   For  connected  endpoints,  receive buffers may be posted prior to connect or accept
       being called on the endpoint.  This ensures that buffers are available to receive incoming
       data immediately after the connection has been established.

       Completed message operations are reported to the user through one or more event collectors
       associated with the endpoint.  Users  provide  context  which  are  associated  with  each
       operation,  and  is  returned  to the user as part of the event completion.  See fi_cq for
       completion event details.

   fi_send
       The call fi_send transfers the data contained in  the  user-specified  data  buffer  to  a
       remote endpoint, with message boundaries being maintained.  For connection based endpoints
       (FI_EP_MSG) the local endpoint must be connected  to  a  remote  endpoint  or  destination
       before  fi_send  is called.  Unless the endpoint has been configured differently, the data
       buffer passed into fi_send must not be touched by the application until the  fi_send  call
       completes asynchronously.

   fi_sendv
       The  fi_sendv  call  adds  support  for  a  scatter-gather  list to fi_send.  The fi_sendv
       transfers the set of data buffers referenced by the iov parameter to a remote endpoint  as
       a single message.

   fi_sendmsg
       The fi_sendmsg call supports data transfers over both connected and unconnected endpoints,
       with the ability to control the send operation per call through the  use  of  flags.   The
       fi_sendmsg function takes a struct fi_msg as input.

              struct fi_msg {
                  const struct iovec *msg_iov; /* scatter-gather array */
                  void               **desc;   /* local request descriptors */
                  size_t             iov_count;/* # elements in iov */
                  fi_addr_t          addr;     /* optional endpoint address */
                  void               *context; /* user-defined context */
                  uint64_t           data;     /* optional message data */
              };

   fi_inject
       The  send  inject call is an optimized version of fi_send.  The fi_inject function behaves
       as if the FI_INJECT transfer flag were set, and FI_COMPLETION were not.  That is, the data
       buffer  is  available  for  reuse  immediately  on  returning  from from fi_inject, and no
       completion event will be generated for this send.  The completion event will be suppressed
       even  if  the  CQ  was  bound  without  FI_SELECTIVE_COMPLETION or the endpoint's op_flags
       contain FI_COMPLETION.  See the flags discussion below for more  details.   The  requested
       message size that can be used with fi_inject is limited by inject_size.

   fi_senddata
       The  send  data  call  is similar to fi_send, but allows for the sending of remote CQ data
       (see FI_REMOTE_CQ_DATA flag) as part of the transfer.

   fi_injectdata
       The inject data call is similar to fi_inject, but allows for the sending of remote CQ data
       (see FI_REMOTE_CQ_DATA flag) as part of the transfer.

   fi_recv
       The  fi_recv  call posts a data buffer to the receive queue of the corresponding endpoint.
       Posted receives are searched in the order in which they were  posted  in  order  to  match
       sends.   Message  boundaries  are maintained.  The order in which the receives complete is
       dependent on the endpoint type and protocol.   For  unconnected  endpoints,  the  src_addr
       parameter  can be used to indicate that a buffer should be posted to receive incoming data
       from a specific remote endpoint.

   fi_recvv
       The fi_recvv call adds support for a scatter-gather list to fi_recv.  The  fi_recvv  posts
       the set of data buffers referenced by the iov parameter to a receive incoming data.

   fi_recvmsg
       The  fi_recvmsg  call  supports  posting  buffers  over  both  connected  and  unconnected
       endpoints, with the ability to control the receive operation per call through the  use  of
       flags.  The fi_recvmsg function takes a struct fi_msg as input.

FLAGS

       The  fi_recvmsg  and fi_sendmsg calls allow the user to specify flags which can change the
       default message handling of the endpoint.  Flags specified with  fi_recvmsg  /  fi_sendmsg
       override  most  flags  previously  configured  with  the endpoint, except where noted (see
       fi_endpoint.3).  The following list of flags are usable with fi_recvmsg and/or fi_sendmsg.

       FI_REMOTE_CQ_DATA : Applies to fi_sendmsg and fi_senddata.  Indicates that remote CQ  data
       is  available  and  should  be sent as part of the request.  See fi_getinfo for additional
       details on FI_REMOTE_CQ_DATA.

       FI_COMPLETION : Indicates that a completion entry should be generated  for  the  specified
       operation.   The endpoint must be bound to a completion queue with FI_SELECTIVE_COMPLETION
       that corresponds to the specified operation, or this flag is ignored.

       FI_MORE : Indicates that the user has additional requests that will immediately be  posted
       after  the current call returns.  Use of this flag may improve performance by enabling the
       provider to optimize its access to the fabric hardware.

       FI_INJECT : Applies to fi_sendmsg.  Indicates that the  outbound  data  buffer  should  be
       returned to user immediately after the send call returns, even if the operation is handled
       asynchronously.  This may require that the underlying  provider  implementation  copy  the
       data into a local buffer and transfer out of that buffer.  This flag can only be used with
       messages smaller than inject_size.

       FI_MULTI_RECV : Applies to posted receive operations.  This flag allows the user to post a
       single  buffer  that  will  receive multiple incoming messages.  Received messages will be
       packed into the receive buffer until the buffer has been consumed.  Use of this  flag  may
       cause a single posted receive operation to generate multiple events as messages are placed
       into the buffer.  The placement of received data into  the  buffer  may  be  subjected  to
       provider specific alignment restrictions.

       The  buffer  will  be released by the provider when the available buffer space falls below
       the specified minimum (see FI_OPT_MIN_MULTI_RECV).  Note that an entry to  the  associated
       receive  completion queue will always be generated when the buffer has been consumed, even
       if other receive  completions  have  been  suppressed  (i.e.   the  Rx  context  has  been
       configured for FI_SELECTIVE_COMPLETION).  See the FI_MULTI_RECV completion flag fi_cq(3).

       FI_INJECT_COMPLETE  :  Applies  to  fi_sendmsg.   Indicates  that  a  completion should be
       generated when the source buffer(s) may be reused.

       FI_TRANSMIT_COMPLETE : Applies to fi_sendmsg.  Indicates that a completion should  not  be
       generated  until  the  operation  has been successfully transmitted and is no longer being
       tracked by the provider.

       FI_DELIVERY_COMPLETE : Applies to fi_sendmsg.   Indicates  that  a  completion  should  be
       generated when the operation has been processed by the destination.

       FI_FENCE  :  Applies  to transmits.  Indicates that the requested operation, also known as
       the fenced operation, be deferred until all previous operations targeting the same  target
       endpoint have completed.

       FI_MULTICAST  :  Applies  to transmits.  This flag indicates that the address specified as
       the data transfer destination is a multicast address.  This  flag  must  be  used  in  all
       multicast transfers, in conjunction with a multicast fi_addr_t.

NOTES

       If an endpoint has been configured with FI_MSG_PREFIX, the application must include buffer
       space of size msg_prefix_size, as specified by the endpoint attributes.  The prefix buffer
       must  occur  at the start of the data referenced by the buf parameter, or be referenced by
       the first IO vector.  Message prefix space cannot be split between  multiple  IO  vectors.
       The size of the prefix buffer should be included as part of the total buffer length.

RETURN VALUE

       Returns  0  on  success.   On  error,  a  negative  value corresponding to fabric errno is
       returned.  Fabric errno values are defined in rdma/fi_errno.h.

       See the discussion below for details handling FI_EAGAIN.

ERRORS

       -FI_EAGAIN : Indicates that the underlying provider currently lacks the  resources  needed
       to  initiate  the requested operation.  The reasons for a provider returning FI_EAGAIN are
       varied.   However,  common  reasons  include  insufficient  internal  buffering  or   full
       processing queues.

       Insufficient  internal  buffering  is often associated with operations that use FI_INJECT.
       In such cases, additional buffering may become available as posted operations complete.

       Full processing queues may be a temporary state related to local processing (for  example,
       a  large  message  is  being  transferred),  or may be the result of flow control.  In the
       latter case, the queues may remain blocked until additional resources are  made  available
       at the remote side of the transfer.

       In  all  cases,  the operation may be retried after additional resources become available.
       It is strongly recommended that applications check for transmit  and  receive  completions
       after  receiving  FI_EAGAIN  as a return value, independent of the operation which failed.
       This  is  particularly  important  in  cases  where  manual  progress  is   employed,   as
       acknowledgements  or  flow  control  messages  may need to be processed in order to resume
       execution.

SEE ALSO

       fi_getinfo(3), fi_endpoint(3), fi_domain(3), fi_cq(3)

AUTHORS

       OpenFabrics.