My concern was more about the “what" factor: what do you write on remote memory in a heterogeneous case. I imagine you can either write the converted data or you can convert remotely after writing. Anyway, on both cases you need intermediary buffers to do the conversion (especially if we are looking a size mismatch), so the interest of RMA is quickly vanishing.
For now, I would just not support heterogeneous environments for RMA. We might want to add a check at windows creation time, so at least the users are warned. George. On Apr 28, 2014, at 13:51 , Nathan Hjelm <hje...@lanl.gov> wrote: > On Mon, Apr 28, 2014 at 01:44:28PM -0400, George Bosilca wrote: >> >> On Apr 28, 2014, at 13:39 , Nathan Hjelm <hje...@lanl.gov> wrote: >> >>> This part of the heterogeneous support being broken was my fault. I >>> fixed it in r31535. I will try to spend some time over the next month or >>> so fixing heterogeneous support in the one-sided code. Right now the >>> packed datatype representation will not work if sizeof (int) is not >>> consistent. >> >> We are consistently using length-aware types (uint32_t) which have the same >> length. However, I would guess that RMA has the same issue as the datatype H >> functions (where the remote displacement cannot be correctly computed >> because we only know the local byte-level displacement). > > Currently, the displacement is computed on the remote side so as long as > the datatype functions in osc/base support heterogenous we should be > good there. Once I finish the optimizations for RDMA networks that may > no longer be the case. I will try to keep the heterogeneous case in mind > as I write this code. > >>> Not sure if we ever claimed to support this case though. >> >> If there is need for conversion, I guess one will have to switch back to the >> pt2pt mode … mode we don’t have anymore. > > The rdma component is more or less the pt2pt component right now. I am > working on re-adding direct RDMA (and atomic) support for a EuroMPI > poster. I don't do any of the header conversion at the moment but it > won't be hard to add. > > -Nathan > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/04/14637.php
