[OFIWG-MPI] Call today

Hefty, Sean sean.hefty at intel.com
Thu May 22 12:23:22 PDT 2014


> [rich]  If the attempt here is to provide a building block that will map to
> different use-case scenarios, then need to have an architecture that will
> map well onto the areas of interest.  MPI is just one such upper level
> service, one that has been called out specifically in the context of the
> proposal you have been presenting.  So, following on this (the precise
> definition of end point is still rather fuzzy at this stage) in general,
> there is no such one-to-one mapping of and endpoint to an MPI matching
> context, but there can be an association of a matching context with one or
> more endpoints.  What I am suggesting here is that we keep data notions
> around data transfer orthogonal to what is done with the data (tag
> matching, in this case).  How the functionality is implemented  (hardware
> or not) is separate from how the stack in architected

Tag matching is an association between data sent over the wire and the receive buffer into which the data should be placed.  This is different than transports that simply match sent data with the buffers using a FIFO ordering scheme.  Conceptually, this seems very similar to RMA writes, where control data carried in the transfer indicates which target side buffer the data should be placed into.  Are you suggesting that RMA operations should be moved outside of the endpoint object as well?

If you have a more specific proposal (and I'll look at what Howard sent out), it may help.  But associating data transfer operations with non-endpoint (or whatever you want to call the base data transfer class) seems unnatural to me.



More information about the ofiwg-mpi mailing list