Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

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.

Subject: Re: [OMPI devel] [EXTERNAL] Re: RTE Framework
From: Barrett, Brian W (bwbarre_at_[hidden])
Date: 2013-01-23 10:24:09

That's not entirely true; there's some state that's required to be held by
the RTE framework (the ompi_process_info structure), but it's minimal and
does not scale with number of peers in a job.

In terms of interface, there's now three MPI frameworks which encompass
the set of functionality the MPI layer needs: rte, pubsub, and dpm (the
last two are the dynamic process stuff). The RTE framework is a fairly
small set of functions, probably 20? I'm hoping we can shrink it slightly
over time, but it's going to require some thought and changes to the OMPI
layer, so I didn't want to do it all in one go.


On 1/23/13 8:03 AM, "Ralph Castain" <rhc_at_[hidden]> wrote:

>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 <richardg_at_[hidden]>
>> 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-bounces_at_[hidden] [mailto:devel-bounces_at_[hidden]] 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:
>> This work is focussed only on the creation of a framework to encompass
>>the RTE interface between OMPI and ORTE. There are currently two
>> 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
>> devel_at_[hidden]
>devel mailing list

  Brian W. Barrett
  Scalable System Software Group
  Sandia National Laboratories

  • application/pkcs7-signature attachment: smime.p7s