Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Well-known mca parameters
From: Ralph Castain (rhc_at_[hidden])
Date: 2014-04-27 09:22:36


On Apr 27, 2014, at 2:26 AM, Mike Dubman <miked_at_[hidden]> wrote:

> MCA infra is very powerful and this use-case can be satisfied by introducing MCA naming convention and checking it programmatically.

Yes, it *can* be - I'm saying that we may not *want* to do it that way. :-)

>
> Changing/updating architecture to fulfill this specific use-case seems a overkill. The arch is powerfull to resolve it w/o adding specific class (IMHO).

Nobody would be changing the architecture of the system. All I'm suggesting is adding a new variable type. Something like "MCA_BASE_VAR_TYPE_VERSION _STRING" instead of "MCA_BASE_VAR_TYPE_STRING". This eliminates the need to force a standard param string format, and may provide a cleaner mechanism.

>
> We had "--bynode" cmd line arg in mpirun before which was a wrapper around specific MCA rmaps param for convenience.
> The well-known MCA can be something similar, i guess.
>
>
>
>
>
> On Fri, Apr 25, 2014 at 5:29 PM, Ralph Castain <rhc_at_[hidden]> wrote:
> So long as this isn't a requirement, I don't see an issue with standardizing the syntax. I suspect Jeff's concern is with hard-coding ompi_info (and all its flavors) with an option that looks for a specific MCA param from every component. Seems somewhat icky from a software design standpoint, and inflexible.
>
> Perhaps creating a special MCA param "class" might make that more palatable? So we aren't looking for a particular string inside an MCA param name when someone gives that ompi_info option, but instead printing all params of a specific type?
>
>
> On Apr 25, 2014, at 4:18 AM, Stephen Poole <swpoole_at_[hidden]> wrote:
>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Although the one Mike suggests would be much easier for "end users", I
>> think that in this
>> case, if the end user is more of a Linux newbie, they would have scripts
>> written for them,
>> that the admins use or will be handed to them. Either way would be a
>> great addition for
>> system/build/runtime verification of the installed libraries.
>>
>> Best
>> Steve...
>>
>>
>> On 4/25/14, 7:13 AM, Jeff Squyres (jsquyres) wrote:
>>> On Apr 25, 2014, at 7:01 AM, Mike Dubman <miked_at_[hidden]> wrote:
>>>
>>>>>>> ompi_info --all --parsable | egrep ':(compile|run)time_version'
>>>>
>>>> yep, this is much better, but I don`t think we should count on
>> end-user to be unix regex guru.
>>>
>>> I thought you said this was for support scripts?
>>>
>>> Users can easily do this:
>>>
>>> ompi_info --all --parsable | grep time_version
>>>
>>> Or even
>>>
>>> ompi_info --all --parsable | grep _version
>>>
>>> Or even
>>>
>>> ompi_info --all --parsable | grep version
>>>
>>>
>>>> Ideally, following would be much user-friendlier:
>>>>
>>>> ompi_info --all --parsable --print-sys-libs-versions
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Apr 25, 2014 at 1:32 PM, Jeff Squyres (jsquyres)
>> <jsquyres_at_[hidden]> wrote:
>>>> On Apr 24, 2014, at 1:38 AM, Mike Dubman <miked_at_[hidden]>
>> wrote:
>>>>
>>>>> ** prefix each well-known MCA param with "print_":
>>>>
>>>> I like the overall idea of this RFC, but I'm not wild about this
>> specific word "print" -- it seems weird. All the MCA parameters are
>> *printed* -- the word "print" doesn't really distinguish anything here.
>>>>
>>>> (I know I'm just harping on a word, but I think it's an important
>> word here... :-) )
>>>>
>>>> Got a better suggestion, perchance? (I don't, offhand...)
>>>>
>>>>> ** Define two well-known mca parameters indicating external library
>> runtime and compiletime versions, i.e.:
>>>>>
>>>>> print_compiletime_version
>>>>> print_runtime_version
>>>>>
>>>>> The following command will show all exposed well-known mca params
>> from all components:
>>>>> ompi_info --parsable -l 9 |grep ":print_"
>>>>
>>>> How about changing this a bit (hoping my regexp syntax is correct at
>> 6:30am before coffee...):
>>>>
>>>> ompi_info --all --parsable | egrep ':(compile|run)time_version'
>>>>
>>>> Then the "print_" prefix isn't needed.
>>>>
>>>> --
>>>> Jeff Squyres
>>>> jsquyres_at_[hidden]
>>>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/04/14610.php
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/04/14611.php
>>>
>>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBAgAGBQJTWkSZAAoJECiO+w6Set8uDWgP/2Lnx2j1foBu85sRtHwIqU72
>> AdQGPvCqbiXZ3Sn32ODJgCE6lGm38W075HqETN3CFfrawvLLpAjsnLs2mdA1GcZq
>> buoPVuFAHQQZ4FM7y+TGUt0NyMAsMDWfBR8t9JdyMZdP7fHYhGitkuGshItivWmQ
>> 0j3KYzKFRe9qVGNvAc+f6eG7DnC+vUFNMZZ6APg62mYB7v//4NGhhrvHpYgD5jG2
>> S3kA1QfvM7xPy6rOL4gvyA6LRnFsNnQmKKLEJFXhPazwy5/5Aop8iwc2TxqVBsZE
>> Jw4B6ZrTKrQCzfuN4vN6jgeYHwhlZHKZqtVDMoIWHKwhJMvXlH8aTmeDqqj6sAfl
>> wknbew6BETuuIkszyRr0BjZrf4zjJ18vqDoRwFNa8p6Wc3cbhK96kl6fXquxTd4z
>> GIuRAIVqemEUGNKnGyuItYuVimkkvts5Ve5c/BxpMBT3oQX1LzOxb6+mcwzdR0dD
>> HK82VQlycFegLQ9+ERLgYEkcfmyZlvB+x/pwtx9RRMOd177w5fCo8hTTnkmWJNq2
>> jfq5cDiAW7knBJ1ZOGvMjp8RDpBMyMHjr6WCxQC3y+szR0TcMWrFUddcM2/2OBxF
>> YfFCP5jaeCQOOmDh1kcntcFoLw43io2xHFr/UwmfXeDhh/IFQrnEmshjvl/ZFF8n
>> RZogS6K9ty1C9x5GCBm4
>> =O0Fa
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/04/14613.php
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/04/14617.php
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/04/14619.php