I was trying to figure out what the new interface provides. Is it supposed to provide the ability to replace entire run-time functionality, does it increase the modularity or the rte, or something else.
Thanks, Rich -----Original Message----- From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain Sent: Wednesday, January 23, 2013 5:05 PM To: Open MPI Developers Subject: Re: [OMPI devel] RTE Framework I'm not entirely sure what you're asking here. There is no state at all in the MPI layer - just a set of function calls. Each component in the ompi/mca/rte framework is required to map those function calls to their own implementation. The function calls themselves are just a rename of the current ORTE calls, so the implementations must provide the same functionality - they are simply free to do so however they choose. On Jan 22, 2013, at 11:31 PM, Richard Graham <richa...@mellanox.com> wrote: > Brian, > First - thanks. I am very happy this is proceeding. > General question here - do you have any idea how much global state sits > behind the current implementation ? What I am trying to gauge at what level > of granularity one can bring in additional capabilities. > I have not looked in detail yet, but will in the near future. > > Thanks, > Rich > > -----Original Message----- > From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On > Behalf Of Barrett, Brian W > Sent: Monday, January 21, 2013 9:31 PM > To: Open MPI Developers > Subject: [OMPI devel] RFC: RTE Framework > > Hi all - > > As discussed at the December developer's meeting, a number of us have been > working on a framework in OMPI to encompass the RTE resources (typically > provided by ORTE). This follows on work Oak Ridge did on the ORCA layer, > which ended up having a number of technical challenges and was dropped for a > simpler approach. > > The interface is still a work in process and designed around the concept that > the ORTE component is a thin renaming around ORTE itself (this was one of the > points the ORTE developers felt strongly about). We think it's ready for > comments and coming into the trunk, so are trying to get it looked at by a > broader community. The Mercurial repository is available > at: > > https://bitbucket.org/rhc/ompi-trunk > > This work is focussed only on the creation of a framework to encompass the > RTE interface between OMPI and ORTE. There are currently two components: > the ORTE component and a test component implemented over PMI. The PMI > component is only really useful if ORTE is disabled at autogen time with the > --no-orte option to autogen. Future work to build against an external OMPI > (in progress, on a different branch) will make using non-orte components > slightly more useful. > > Anyway, if there aren't any major comments, I'll plan on bringing this work > to the trunk this weekend (Jan 26/27). > > Brian > > -- > Brian W. Barrett > Scalable System Software Group > Sandia National Laboratories > > > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel _______________________________________________ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
