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 <mi...@dev.mellanox.co.il> 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 <r...@open-mpi.org> 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
