Re: [OMPI devel] RFC: Multiple duplicate MCA param generates error

[Jeff Squyres (jsquyres)]

On Sep 9, 2014, at 1:42 PM, Mike Dubman  wrote:

> maybe we should have another MCA parameter to specify desired policy? 
> LAST,CONCAT,FIRST and let user select it?
> 
> basically, it is to mimic "setenv(var,val,overwrite)" behavior which is easy 
> to explain and good to have.

Is there a use case for this behavior?

-x behavior is different than MCA param setting behavior.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] RFC: Multiple duplicate MCA param generates error

[Ralph Castain]

I can't see how a user would know how to use such a thing - which mca params 
can absorb a concatenated value? Why would you take the last vs the first 
instead of just providing a value only once?


On Sep 9, 2014, at 10:42 AM, Mike Dubman  wrote:

> maybe we should have another MCA parameter to specify desired policy? 
> LAST,CONCAT,FIRST and let user select it?
> 
> basically, it is to mimic "setenv(var,val,overwrite)" behavior which is easy 
> to explain and good to have.
> 
> 
> On Tue, Sep 9, 2014 at 7:31 PM, Ralph Castain  wrote:
> WHAT: Generate an error if the user provides duplicate MCA params on the 
> cmd line
> 
> WHY:   User confusion due to unexpected behavior
> 
> WHEN: Tues, Sept 16 as this is a gating issue for 1.8.3 release
> 
> 
> In the beginning, OMPI would look at a cmd line for MCA params - if a param 
> was listed more than once, we would take the LAST value given and ignore all 
> the rest. At some point, this behavior was changed in 
> opal/mca/base/mca_base_cmd_line.c such that we concatenated the values into a 
> comma-delimited list. Unfortunately, the backend parser doesn't know how to 
> deal with such a list when converting the param to values such as INT or BOOL.
> 
> In r32686, I reverted the behavior back to the original one of taking the 
> LAST value. However, this can lead to unexpected behavior. For example, 
> consider the case where the user provides a cmd line containing the following:
> 
> ... -mca btl ^sm. -mca btl openib.
> 
> In this case, the result will be a setting of "btl=openib", and only the 
> openib BTL will be selected. If the user thought that all BTLs other than sm 
> were to be considered, this could be a surprise. Likewise, note that if the 
> order is reversed, the result would be "btl=^sm" - a completely different 
> behavior.
> 
> On the telecon, we couldn't think of any use-case where we would want the 
> last value or concatenating behaviors. Instead, there was consensus that we 
> should generate an error as the user is asking us to do conflicting things.
> 
> However, we acknowledged that we might not understand all the use-cases, so 
> we are issuing this as an RFC in case someone knows of a reason for the other 
> behaviors.
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/09/15782.php
> 
> 
> 
> -- 
> 
> Kind Regards,
> 
> M.
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/09/15784.php

Re: [OMPI devel] RFC: Multiple duplicate MCA param generates error

[Mike Dubman]

maybe we should have another MCA parameter to specify desired policy?
LAST,CONCAT,FIRST and let user select it?

basically, it is to mimic "setenv(var,val,overwrite)" behavior which is
easy to explain and good to have.


On Tue, Sep 9, 2014 at 7:31 PM, Ralph Castain  wrote:

> WHAT: Generate an error if the user provides duplicate MCA params on
> the cmd line
>
> WHY:   User confusion due to unexpected behavior
>
> WHEN: Tues, Sept 16 as this is a gating issue for 1.8.3 release
>
>
> In the beginning, OMPI would look at a cmd line for MCA params - if a
> param was listed more than once, we would take the LAST value given and
> ignore all the rest. At some point, this behavior was changed in
> opal/mca/base/mca_base_cmd_line.c such that we concatenated the values into
> a comma-delimited list. Unfortunately, the backend parser doesn't know how
> to deal with such a list when converting the param to values such as INT or
> BOOL.
>
> In r32686, I reverted the behavior back to the original one of taking the
> LAST value. However, this can lead to unexpected behavior. For example,
> consider the case where the user provides a cmd line containing the
> following:
>
> ... -mca btl ^sm. -mca btl openib.
>
> In this case, the result will be a setting of "btl=openib", and only the
> openib BTL will be selected. If the user thought that all BTLs other than
> sm were to be considered, this could be a surprise. Likewise, note that if
> the order is reversed, the result would be "btl=^sm" - a completely
> different behavior.
>
> On the telecon, we couldn't think of any use-case where we would want the
> last value or concatenating behaviors. Instead, there was consensus that we
> should generate an error as the user is asking us to do conflicting things.
>
> However, we acknowledged that we might not understand all the use-cases,
> so we are issuing this as an RFC in case someone knows of a reason for the
> other behaviors.
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/09/15782.php
>



-- 

Kind Regards,

M.