[libfabric-users] provider developer documentation

Blocksome, Michael michael.blocksome at intel.com
Tue Feb 7 15:22:04 PST 2017

For compiling MPICH/CH4/OFI the pertinent ofi features required of the provider are specified via “capability sets” (basically a collection of ofi features).


* The definitions map to these capability sets:
* MPIDI_OFI_ENABLE_DATA               fi_tsenddata (and other functions with immediate data)
*                                                Uses FI_REMOTE_CQ_DATA, FI_DIRECTED_RECV
* MPIDI_OFI_ENABLE_SCALABLE_ENDPOINTS fi_scalable_ep instead of fi_ep
*                                     domain_attr.max_ep_tx_ctx > 1
* MPIDI_OFI_ENABLE_STX_RMA            Use shared transmit contexts for RMA
*                                     Uses FI_SHARED_CONTEXT
*                                     If using runtime mode, this will be set to FI_MR_UNSPEC
* MPIDI_OFI_ENABLE_TAGGED             Use FI_TAGGED interface instead of FI_MSG
* MPIDI_OFI_ENABLE_AM                 Use FI_MSG and FI_MULTI_RECV for active messages
* MPIDI_OFI_ENABLE_RMA                Use FI_ATOMICS and FI_RMA interfaces
* MPIDI_OFI_FETCH_ATOMIC_IOVECS       The maximum number of iovecs that can be used for fetch_atomic operations

most things you can turn off, but some stuff is required. You need to support one of the two address vector types, a memory region type (if rma and/or atomics), etc.  In general, you need “FI_MSG and FI_MULTI_RECV” to get MPICH bootstrapped, the rest is sugar.

Of course all MPIs are different … this is just for MPICH.


-----Original Message-----
From: Libfabric-users [mailto:libfabric-users-bounces at lists.openfabrics.org] On Behalf Of Hefty, Sean
Sent: Tuesday, February 7, 2017 5:18 PM
To: Robert Cauble <rcauble at google.com>
Cc: ofiwg at lists.openfabrics.org; libfabric-users at lists.openfabrics.org
Subject: Re: [libfabric-users] provider developer documentation

> You mention "minimal amount of the API" -- I would like to do that for
> starters. Are there guidelines WRT which operations/features are
> required by various MPI implementations and implications for not
> supporting them (loss of functionality vs loss of performance?)

I think this greatly depends on the MPI.  :)  The target minimal amount of work depends on your hardware.  The expectation is that the utility layers will provide the rest.  Note that the utility layers are designed for performance, just may not be optimal for the underlying hardware.  (We are actively working on the utility code, so fully drop in support isn't there yet.)

If your target HW just sends/receives packets, you can aim for the functionality supported by the UDP provider -- DGRAM EPs with simple send/receive support.  If your target HW works best with connection-oriented communication, I would mimic the verbs provider -- MSG EPs with RMA and shared receive contexts.  For reliable-unconnected hardware, I would implement support for the tagged interfaces first.

I'm not familiar enough with the MPI implementations to know what features are optional versus required.
Libfabric-users mailing list
Libfabric-users at lists.openfabrics.org

More information about the Libfabric-users mailing list