Ralph, We do not have such infrastructure as there are too many possibilities to handle efficiently. However, different projects (Mellanox and NVidia) are using techniques that look similar to what you propose.
The main idea is to replace the default behavior of the convertor with a BTL-specialized function that understand some of the MPI datatype constructs. This is realized by setting your own pack/unpack functions in the convertor (as the internal description of the datatype is relatively well described in the headers one can implement such functions easily). In case the cost of reevaluating the datatype description is too costly, the attribute table attached to the datatype can be used as a cache. George. On Fri, May 20, 2016 at 9:22 AM, Ralph Castain <r...@open-mpi.org> wrote: > Hey folks > > Is there some flag by which the datatype code can know what transport is > being used? For example, suppose a transport can handle certain datatype > configurations itself, without the converting dealing with them (e.g., > contiguous vs non-contiguous). Essentially, it’s an “offload” capability. > Although the convertor is currently assigned on a per-peer basis, the logic > in such cases might also depend upon the capabilities of the transport > being used to communicate to that peer. > > So I’m wondering if we have some mechanism by which that capability can be > communicated to the datatype code down in OPAL? > Ralph > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2016/05/19008.php
