Re: [OMPI devel] [OMPI svn] svn:open-mpi r18677
I guess I had thought that this new model fit nicely within abstraction barriers -- ask the component to "do whatever you need to do to warmup your routes". The knowledge how to do that is already down in that component; is there really a reason/need to export it higher? On Jun 19, 2008, at 12:05 PM, George Bosilca wrote: Ralph, I don't necessarily agree with this statement. There is a generic method to do the correct wireup, and this method works independent of the selected routed algorithms. One can use the routed to ask for the next hop for each of the destinations, make a unique list out of these first hop destinations, and then finally generate the connections to them. Of course there is a cost associated with this method. Creating the temporary list will be a quite expensive, but this list will be smaller for highly optimized routed components. Eventually, a more optimized approach will be to use the get_routing_tree function in order to gather the direct routes, and then start the connections to these children. This approach is not more complex than the current implementation, and give us the benefit of having a consistent behavior in all cases. george. On Jun 19, 2008, at 3:48 PM, r...@osl.iu.edu wrote: Author: rhc Date: 2008-06-19 09:48:26 EDT (Thu, 19 Jun 2008) New Revision: 18677 URL: https://svn.open-mpi.org/trac/ompi/changeset/18677 Log: Shift responsibility for preconnecting the oob to the orte routed framework, which is the only place that knows what needs to be done. Only the direct module will actually do anything - it uses the same algo as the original preconnect function. Text files modified: trunk/ompi/mca/dpm/dpm.h| 7 +- trunk/ompi/runtime/mpiruntime.h | 1 trunk/ompi/runtime/ompi_mpi_init.c |29 ++ +-- trunk/ompi/runtime/ompi_mpi_preconnect.c|80 --- trunk/orte/mca/grpcomm/basic/grpcomm_basic_module.c |13 - trunk/orte/mca/odls/base/odls_base_default_fns.c| 5 + trunk/orte/mca/routed/binomial/routed_binomial.c|20 +++ ++ trunk/orte/mca/routed/direct/routed_direct.c|56 +++ trunk/orte/mca/routed/linear/routed_linear.c| 7 +++ trunk/orte/mca/routed/routed.h |10 trunk/orte/orted/orted_comm.c | 5 ++ trunk/orte/util/nidmap.c|81 +++ +++- 12 files changed, 184 insertions(+), 130 deletions(-) ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
Re: [OMPI devel] [OMPI svn] svn:open-mpi r18677
I would argue that this behavior is in fact consistent - the returned state is that all required connections have been opened and is independent of the selected routed module. How that is done is irrelevant to the caller. Each routed module knows precisely what connections are used for its operation. It is therefore trivial for it to internally do the right thing. For example, in the binomial case, no communication is required whatsoever for an MPI proc (only a daemon would ever warmup its connections to its parent and/or children). In the direct module, the old wireup is required. In a topo-aware module, we may want to do some other pattern. In all cases, the precise pattern to be used depends upon whether we are warming up the connections of a daemon, the HNP, or an application process. We will shortly be calling "warmup_routes" for all three cases, though for now the actions taken may be "null" in some cases. So we might as well let each routed module do what it thinks is required. I don't see much advantage in having something that digs the info out of the module, and then attempts to reconstruct what the module already knew how to do. What matters is that the end state is consistent - what happens under the covers is solely determined by the selected routed module. Ralph On 6/19/08 10:05 AM, "George Bosilca" wrote: > Ralph, > > I don't necessarily agree with this statement. There is a generic > method to do the correct wireup, and this method works independent of > the selected routed algorithms. > > One can use the routed to ask for the next hop for each of the > destinations, make a unique list out of these first hop destinations, > and then finally generate the connections to them. Of course there is > a cost associated with this method. Creating the temporary list will > be a quite expensive, but this list will be smaller for highly > optimized routed components. Eventually, a more optimized approach > will be to use the get_routing_tree function in order to gather the > direct routes, and then start the connections to these children. This > approach is not more complex than the current implementation, and give > us the benefit of having a consistent behavior in all cases. > >george. > > On Jun 19, 2008, at 3:48 PM, r...@osl.iu.edu wrote: > >> Author: rhc >> Date: 2008-06-19 09:48:26 EDT (Thu, 19 Jun 2008) >> New Revision: 18677 >> URL: https://svn.open-mpi.org/trac/ompi/changeset/18677 >> >> Log: >> Shift responsibility for preconnecting the oob to the orte routed >> framework, which is the only place that knows what needs to be done. >> Only the direct module will actually do anything - it uses the same >> algo as the original preconnect function. >> >> Text files modified: >> trunk/ompi/mca/dpm/dpm.h| 7 +- >> trunk/ompi/runtime/mpiruntime.h | 1 >> trunk/ompi/runtime/ompi_mpi_init.c |29 ++ >> +-- >> trunk/ompi/runtime/ompi_mpi_preconnect.c|80 >> --- >> trunk/orte/mca/grpcomm/basic/grpcomm_basic_module.c |13 - >> trunk/orte/mca/odls/base/odls_base_default_fns.c| 5 + >> trunk/orte/mca/routed/binomial/routed_binomial.c|20 +++ >> ++ >> trunk/orte/mca/routed/direct/routed_direct.c|56 +++ >> >> trunk/orte/mca/routed/linear/routed_linear.c| 7 +++ >> trunk/orte/mca/routed/routed.h |10 >> trunk/orte/orted/orted_comm.c | 5 ++ >> trunk/orte/util/nidmap.c|81 +++ >> +++- >> 12 files changed, 184 insertions(+), 130 deletions(-) > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] [OMPI svn] svn:open-mpi r18677
Ralph, I don't necessarily agree with this statement. There is a generic method to do the correct wireup, and this method works independent of the selected routed algorithms. One can use the routed to ask for the next hop for each of the destinations, make a unique list out of these first hop destinations, and then finally generate the connections to them. Of course there is a cost associated with this method. Creating the temporary list will be a quite expensive, but this list will be smaller for highly optimized routed components. Eventually, a more optimized approach will be to use the get_routing_tree function in order to gather the direct routes, and then start the connections to these children. This approach is not more complex than the current implementation, and give us the benefit of having a consistent behavior in all cases. george. On Jun 19, 2008, at 3:48 PM, r...@osl.iu.edu wrote: Author: rhc Date: 2008-06-19 09:48:26 EDT (Thu, 19 Jun 2008) New Revision: 18677 URL: https://svn.open-mpi.org/trac/ompi/changeset/18677 Log: Shift responsibility for preconnecting the oob to the orte routed framework, which is the only place that knows what needs to be done. Only the direct module will actually do anything - it uses the same algo as the original preconnect function. Text files modified: trunk/ompi/mca/dpm/dpm.h| 7 +- trunk/ompi/runtime/mpiruntime.h | 1 trunk/ompi/runtime/ompi_mpi_init.c |29 ++ +-- trunk/ompi/runtime/ompi_mpi_preconnect.c|80 --- trunk/orte/mca/grpcomm/basic/grpcomm_basic_module.c |13 - trunk/orte/mca/odls/base/odls_base_default_fns.c| 5 + trunk/orte/mca/routed/binomial/routed_binomial.c|20 +++ ++ trunk/orte/mca/routed/direct/routed_direct.c|56 +++ trunk/orte/mca/routed/linear/routed_linear.c| 7 +++ trunk/orte/mca/routed/routed.h |10 trunk/orte/orted/orted_comm.c | 5 ++ trunk/orte/util/nidmap.c|81 +++ +++- 12 files changed, 184 insertions(+), 130 deletions(-)
