[mpiwg-tools] Open MPI pvar scheme
Schulz, Martin
schulzm at llnl.gov
Mon Nov 11 17:37:42 CST 2013
Hi Jeff,
On Nov 11, 2013, at 2:53 PM, "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
wrote:
> On Nov 11, 2013, at 5:34 PM, Kathryn Mohror <kathryn at llnl.gov> wrote:
>
>>> The answer we're currently using is what we discussed on the tools call: <prefix> is a state variable with enumeration, and all <prefix><name> pvars are expected to use the mapping of that state variable. For exmple, btl_usnic_num_sends will follow the pattern established by the btl_usnic pvar state variable.
>>
>> I guess the problem with this (and maybe I'm missing something) is that it will be hard for a tool to know if a particular state variable with an enumeration describes other variables that have the prefix in their names. In other words, how do I know that this state variable is special and not just that some pvars happen to have the same prefix, but there's no relationship between them?
>
> I think what we're trying to say is this:
>
> - for a given pvar category X
> - if there's a state pvar Y (which therefore has an associated enumeration)
> - then any pvar in category X that has a name that begins with Y is related to state pvar Y
>
> This has the restriction that you shouldn't give a state pvar a name that is a prefix of some other pvar in the same category (i.e., so that you don't get incorrect relationship implications).
>
> Since this convention is limited to a single category, it may not be too onerous.
Just to clarify: are you proposing that we add this officially to the standard (that particular naming scheme) or is this supposed to be an informal agreement? I personally would like to see the former, since it will be important to have something tools can rely on. Assuming you meant that (that's how I understood it), here is one concern: this scheme is not very flexible - once a name is set and the enumeration variable is provided, this cannot be changed anymore. Isn't this even too restrictive for your case (where NICs can come and go in, e.g., a hot-pluggable system)?
In general, the situation can appear in any scenario in which we have a variable that can (doesn't have to at the moment) return a value of more than 1 for the count. Depending on the variable, it can vary greatly in what that means and this can be very dynamic. I think a more dynamic lookup mechanism (e.g., query an enumeration once you have a count and a handle) would be better.
Martin
>
> --
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA
More information about the mpiwg-tools
mailing list