[mpiwg-tools] Open MPI pvar scheme

[Schulz, Martin]

Hi Jeff,

On Nov 11, 2013, at 3:46 PM, "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
 wrote:

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

Oh, I see.

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

I agree with that, but I see it more as an MPI 3.1 feature. Is it really a major concept?

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

So that's a good question - I was assuming (at least that's how I always thought about it) that the same rules as for variables and all their metadata apply here - once read, a description cannot change and an enumeration type can worst thing grow. It is correct, though, that we didn't specify that explicitly - perhaps we need to do that. The only text that comes close is "The second datatype class, enumeration datatypes, describes variables with a fixed set of discrete values.". Having strings change underneath would be a real problem for the string interface, since it makes the assumption that you can run queries against a string more than once and get the same string.

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

Yes, but the count can change when you get a new handle.

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

Yes, that's what I meant with "doesn't have to be at the moment" - any variable that has the potential to have a count that is not 1 is affected.

Martin


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

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA