[Mpi3-rma] MPI3 RMA Design Goals

[Jeff Hammond]

Vinod,

> For networks that do require registration, many on-the-fly registration
> strategies have been proposed. In this case, the MPI keeps track of what has
> been registered and what has not been registered. Clearly, if the user were
> to register this memory (and indicate to the implementation that the memory
> has been registered), implementation can optimize data transfers (this has
> been discussed in literature too). Using an object such as origin_mem will
> alleviate this problem. However, requiring doing this for every operation
> may be an unnecessary programming burden. We can discuss the pros and cons
> of either in detail.

Could both be supported by making memobj one option for
origin_datatype?  On platforms where registration was necessary, one
would pay a penalty when using simple semantics or get better
performance when using a memobj descriptor.  On platforms where
registration is not necessary or no-copy is not possible, the two
variants would behave similarly.  This option should be portable with
the only variation appearing in the first case noted.

> I think what you are asking for is another version of these interfaces that
> take memory_object+offset as inputs for both target and origin. The reason
> you are asking for this is that you believe implementations can guarantee
> zero-copy data transfers (I don't think this can be guaranteed across many
> systems) and enforce access restrictions you may impose on these memory
> objects. But first, for that, the memory object will need to encapsulate the
> access information as well. Correct me if I am missing your intent.

Clearly it is impossible to guarantee no-copy transfers on platforms
which do not support them.  My intent is only to ensure that no-copy
is possible on platforms which do support it.  I do not know enough
about implementation details to be sure that not using a memobj
locally will always permit no-copy operations when the platform
supports this, but I hope the standard is such that implementing
no-copy is relatively easy when possible.

Best,

Jeff

-- 
Jeff Hammond
Argonne Leadership Computing Facility
jhammond at mcs.anl.gov / (630) 252-5381
http://www.linkedin.com/in/jeffhammond
http://home.uchicago.edu/~jhammond/