> Exactly. However, we should be careful about what we are adding here. A > strided interface is a very specific special case that applies to regular > problems. There is a bready of MPI derived datatype capabilities that are > not covered by a simple stride. What are the objectives for covering > datatypes? Is the IOVEC interface the right place to glue in the first > handling of a special case of datatypes?
I believe I can add strided IOVs to the existing APIs without impacting the performance or usability of current calls, while still keeping strided IOV simple to use. Adding user-defined data types to a network API sounds ludicrous IMO. In any case, I would need to study this use case more before beginning to design it. If strided IOVs are not useful enough by themselves, then the concept should be dropped. Otherwise, we can expand the API to include just that feature. What I want to avoid is forcing apps to use of some convoluted (but highly flexible!) mechanism in order to take advantage of a feature. - Sean _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
