[mpiwg-tools] Open MPI pvar scheme

[Jeff Squyres (jsquyres)]

On Nov 11, 2013, at 6:37 PM, "Schulz, Martin" <schulzm at llnl.gov> wrote:

> 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?

The latter.

> I personally would like to see the former, since it will be important to have something tools can rely on.

I think it would be better to programmatically express such relationships -- i.e., something new for MPI-4.

> 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)?

Er... I don't understand.  Why can't the enum strings change?  I think they can change at any time.

I think what you might be saying is that the *count* on a handle can't change -- right?  I.e., MPI_T currently has no way of saying, "There were N values when you called pvar_handle_alloc() for this pvar, but now this pvar has M values."

Right?

If so, that's really a different (but still potentially valid) issue.

> 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.


I don't think this is only for pvars with a count>1.  What if N=1 and M=3 in the previous example?

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