This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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.
On 6/19/08 10:05 AM, "George Bosilca" <bosilca_at_[hidden]> wrote:
> 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.
> On Jun 19, 2008, at 3:48 PM, rhc_at_[hidden] 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
>> 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