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] v1.3 RM: need a ruling
From: Ralph H Castain (rhc_at_[hidden])
Date: 2008-07-11 10:04:49


On 7/11/08 7:48 AM, "Terry Dontje" <Terry.Dontje_at_[hidden]> wrote:

> Jeff Squyres wrote:
>> Check that -- Ralph and I talked more about #1383 and have come up
>> with a decent/better solution that a) is not wonky and b) does not
>> involve MCA parameter synonyms. We're working on it in an hg and will
>> put it back when done (probably within a business day or three).
>>
>> So I think the MCA synonym stuff *isn't* needed for v1.3 after all.
>>
> I am not dead yet!!!
>
> So, there was also the name change of pls_rsh_agent to plm_rsh_agent
> because the pls's were sucked into plm's (or so I believe). Anyways,
> this seems like another case to support synonyms. Also are there other
> pls mca parameters that have had their names changed to plm?

I think you're opening a really ugly can of worms. How far back do you want
to go? v1.0? v0.1? We have a history of changing mca param names across
major releases, so trying to keep everything alive could well become a
nightmare.

I would hate to try and figure out all the changes - and what about the
params that simply have disappeared, or had their functionality absorbed by
some combination of other params?

My head aches already... :-)

Ralph

>
> --td
>> I think the MCA param synonyms and "deprecated" stuff is useful for
>> the future, but at this point, nothing in v1.3 would use it. So my
>> $0.02 is that we should leave it out.
>>
>>
>>
>> On Jul 10, 2008, at 2:00 PM, Jeff Squyres (jsquyres) wrote:
>>
>>> K, will do. Note that it turns out that we did not yet solve the
>>> mpi_paffinity_alone issue, but we're working on it. I'm working on
>>> the IOF issue ATM; will return to mpi_paffinity_alone in a bit...
>>>
>>>
>>> On Jul 10, 2008, at 1:56 PM, George Bosilca wrote:
>>>
>>>> I'm 100% with Brad on this. Please go ahead and include this feature
>>>> in the 1.3.
>>>>
>>>> george.
>>>>
>>>> On Jul 10, 2008, at 11:33 AM, Brad Benton wrote:
>>>>
>>>>> I think this is very reasonable to go ahead and include for 1.3. I
>>>>> find that preferable to a 1.3-specific "wonky" workaround. Plus,
>>>>> this sounds like something that is very good to have in general.
>>>>>
>>>>> --brad
>>>>>
>>>>>
>>>>> On Wed, Jul 9, 2008 at 8:49 PM, Jeff Squyres <jsquyres_at_[hidden]>
>>>>> wrote:
>>>>> v1.3 RMs: Due to some recent work, the MCA parameter
>>>>> mpi_paffinity_alone disappeared -- it was moved and renamed to be
>>>>> opal_paffinity_alone. This is Bad because we have a lot of
>>>>> historical precent based on the MCA param name
>>>>> "mpi_paffinity_alone" (FAQ, PPT presentations, e-mails on public
>>>>> lists, etc.). So it needed to be restored for v1.3. I just
>>>>> noticed that I hadn't opened a ticket on this -- sorry -- I opened
>>>>> #1383 tonight.
>>>>>
>>>>> For a variety of reasons described in the commit message r1383,
>>>>> Lenny and I first decided that it would be best to fix this problem
>>>>> by the functionality committed in r18770 (have the ability to find
>>>>> out where an MCA parameter was set). This would allow us to
>>>>> register two MCA params: mpi_paffinity_alone and
>>>>> opal_paffinity_alone, and generally do the Right Thing (because we
>>>>> could then tell if a user had set a value or whether it was a
>>>>> default MCA param value). This functionality will also be useful
>>>>> in the openib BTL, where there is a blend of MCA parameters and INI
>>>>> file parameters.
>>>>>
>>>>> However, after doing that, it seemed like only a few more steps to
>>>>> implement an overall better solution: implement "synonyms" for MCA
>>>>> parameters. I.e., register the name "mpi_paffinity_alone" as a
>>>>> synonym for opal_paffinity_alone. Along the way, it was trivial to
>>>>> add a "deprecated" flag for MCA parameters that we no longer want
>>>>> to use anymore (this deprecated flag is also useful in the OB1 PML
>>>>> and openib BTL).
>>>>>
>>>>> So to fix a problem that needed to be fixed for v1.3 (restore the
>>>>> MCA parameter "mpi_paffinity_alone"), I ended up implementing new
>>>>> functionality.
>>>>>
>>>>> Can this go into v1.3, or do we need to implement some kind of
>>>>> alternate fix? (I admit to not having thought through what it
>>>>> would take to fix without the new MCA parameter functionality -- it
>>>>> might be kinda wonky)
>>>>>
>>>>> --
>>>>> Jeff Squyres
>>>>> Cisco Systems
>>>>>
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>> devel_at_[hidden]
>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>>
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>> devel_at_[hidden]
>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>
>>>
>>> --
>>> Jeff Squyres
>>> Cisco Systems
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel