We are also targeting RDM for now, but I agree that the two may diverge at some point, and so flexibility makes sense. Only wish that libfabric had a decent shared memory provider...
> On Mar 17, 2016, at 7:10 AM, Howard <hpprit...@gmail.com> wrote: > > I think that's a better approach. Not clear you'd want to use same EP type as > BTL. I'm going for RDM type for now for BTL. > > Howard > > Von meinem iPhone gesendet > > Am 16.03.2016 um 09:35 schrieb Ralph Castain <r...@open-mpi.org > <mailto:r...@open-mpi.org>>: > >> Interesting! Yeah, we debated about BTL or go direct to OFI. Finally opted >> for the latter as it seemed simpler than the BTL interface. >> >>> On Mar 16, 2016, at 7:29 AM, Howard <hpprit...@gmail.com >>> <mailto:hpprit...@gmail.com>> wrote: >>> >>> Hi Ralph >>> >>> I dont know if it's relevant, but I'm working on an ofi BTL so we can use >>> the OSC rdma. >>> >>> Howard >>> >>> Von meinem iPhone gesendet >>> >>> Am 15.03.2016 um 17:21 schrieb Ralph Castain <r...@open-mpi.org >>> <mailto:r...@open-mpi.org>>: >>> >>>> Hi folks >>>> >>>> We are working on integrating the RML with libfabric so we have access to >>>> both management Ethernet and fabric transports. A first step in enabling >>>> this is to convert the RML framework to multi-select of active components. >>>> The stub functions then scan the components in priority order until one >>>> can perform the requested action (e.g., send a buffer). This will allow us >>>> to simultaneously support both OFI and other components. >>>> >>>> While making this change, we also: >>>> >>>> * removed the qos framework - this functionality has been moved to another >>>> library that builds on top of the RML >>>> >>>> * removed the ftrm component - this was stale, and it wasn’t clear to us >>>> how it would change under the new architecture >>>> >>>> We will be adding the new OFI component in a separate PR. This just >>>> contains the change to a multi-select framework. >>>> >>>> The PR is here: https://github.com/open-mpi/ompi/pull/1457 >>>> <https://github.com/open-mpi/ompi/pull/1457> >>>> >>>> Please feel free to comment and/or make suggestions >>>> Ralph >>>> >>>> _______________________________________________ >>>> devel mailing list >>>> de...@open-mpi.org <mailto:de...@open-mpi.org> >>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>> <http://www.open-mpi.org/mailman/listinfo.cgi/devel> >>>> Link to this post: >>>> http://www.open-mpi.org/community/lists/devel/2016/03/18699.php >>>> <http://www.open-mpi.org/community/lists/devel/2016/03/18699.php>_______________________________________________ >>> devel mailing list >>> de...@open-mpi.org <mailto:de...@open-mpi.org> >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> <http://www.open-mpi.org/mailman/listinfo.cgi/devel> >>> Link to this post: >>> http://www.open-mpi.org/community/lists/devel/2016/03/18702.php >>> <http://www.open-mpi.org/community/lists/devel/2016/03/18702.php> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org <mailto:de...@open-mpi.org> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> <http://www.open-mpi.org/mailman/listinfo.cgi/devel> >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2016/03/18703.php >> <http://www.open-mpi.org/community/lists/devel/2016/03/18703.php>_______________________________________________ > 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/2016/03/18709.php
