NAME

       fi_shm - The SHM Fabric Provider

OVERVIEW

       The  SHM  provider  is  a  complete  provider that can be used on Linux systems supporting
       shared memory and process_vm_readv/process_vm_writev calls.  The provider is  intended  to
       provide high-performance communication between processes on the same system.

SUPPORTED FEATURES

       This  release  contains  an  initial  implementation  of  the SHM provider that offers the
       following support:

       Endpoint types : The provider supports only endpoint type FI_EP_RDM.

       Endpoint capabilities : Endpoints cna support  any  combinations  of  the  following  data
       transfer  capabilities: FI_MSG, FI_TAGGED, FI_RMA, amd FI_ATOMICS.  These capabilities can
       be  further  defined  by  FI_SEND,  FI_RECV,  FI_READ,   FI_WRITE,   FI_REMOTE_READ,   and
       FI_REMOTE_WRITE to limit the direction of operations.

       Modes : The provider does not require the use of any mode bits.

       Progress  :  The  SHM provider supports FI_PROGRESS_MANUAL.  Receive side data buffers are
       not modified outside of completion processing routines.  The provider  processes  messages
       using  three  different  methods,  based on the size of the message.  For messages smaller
       than 4096 bytes, tx completions are generated immediately  after  the  send.   For  larger
       messages,  tx  completions  are  not  generated until the receiving side has processed the
       message.

       Address Format : The SHM provider uses the address format FI_ADDR_STR, which  follows  the
       general format pattern "[prefix]://[addr]".  The application can provide addresses through
       the node or hints parameter.  As long as the address is  in  a  valid  FI_ADDR_STR  format
       (contains "://"), the address will be used as is.  If the application input is incorrectly
       formatted or no input was provided, the SHM provider will  resolve  it  according  to  the
       following SHM provider standards:

       (flags   &   FI_SOURCE)   ?    src_addr   :   dest_addr   =  -  if  (node  &&  service)  :
       "fi_ns://node:service" - if (service) :  "fi_ns://service"  -  if  (node  &&  !service)  :
       "fi_shm://node" - if (!node && !service) : "fi_shm://PID"

       !(flags & FI_SOURCE) - src_addr = "fi_shm://PID"

       In  other  words,  if  the  application provides a source and/or destination address in an
       acceptable FI_ADDR_STR format (contains "://"), the call to util_getinfo will successfully
       fill  in  src_addr  and  dest_addr  with  the  provided  input.  If the input is not in an
       ADDR_STR format, the shared memory provider will then create a proper FI_ADDR_STR  address
       with  either  the  "fi_ns://"  (node/service  format) or "fi_shm://" (shm format) prefixes
       signaling whether the addr is a "unique" address and  does  or  does  not  need  an  extra
       endpoint  name  identifier  appended  in  order  to make it unique.  For the shared memory
       provider, we assume that the service (with or without a node) is enough to make it unique,
       but a node alone is not sufficient.  If only a node is provided, the "fi_shm://" prefix is
       used to signify that it is not a unique address.  If no node or service are provided  (and
       in  the  case  of  setting the src address without FI_SOURCE and no hints), the process ID
       will be used as a default  address.   On  endpoint  creation,  if  the  src_addr  has  the
       "fi_shm://"  prefix,  the  provider will append ":[dom_idx]:[ep_idx]" as a unique endpoint
       name (essentially, in place of a service).  In the case of the "fi_ns://" prefix  (or  any
       other  prefix  if  one  was  provided  by the application), no supplemental information is
       required to make it unique and it will remain with only the  application-defined  address.
       Note that the actual endpoint name will not include the FI_ADDR_STR "*://" prefix since it
       cannot be included in any shared memory region names.  The provider  will  strip  off  the
       prefix    before    setting   the   endpoint   name.    As   a   result,   the   addresses
       "fi_prefix1://my_node:my_service" and "fi_prefix2://my_node:my_service"  would  result  in
       endpoints  and  regions  of the same name.  The application can also override the endpoint
       name after creating an endpoint using setname() without any address format restrictions.

       Msg flags The provider currently only supports the FI_REMOTE_CQ_DATA msg flag.

       MR registration mode The provider implements FI_MR_VIRT_ADDR memory mode.

       Atomic operations The provider supports all combinations of  datatype  and  operations  as
       long as the message is less than 4096 bytes (or 2048 for compare operations).

LIMITATIONS

       The  SHM  provider  has  hard-coded maximums for supported queue sizes and data transfers.
       These values are reflected in the related fabric attribute structures

       EPs must be bound to both RX and TX CQs.

       No support for selective completions or multi-recv.

       No support for counters.

RUNTIME PARAMETERS

       No runtime parameters are currently defined.

SEE ALSO

       fabric(7), fi_provider(7), fi_getinfo(3)

AUTHORS

       OpenFabrics.