<div dir="ltr">







Let me comment on the problem in your slides of last teleconf:<br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">Slide 2: "Problem: multiple network devices on a server – want to return the number of sends on each device but don’t want to create a new variable for each of them.<br>
  Solution: have each performance variable return an array of values; one for each underlying network device"<br><br></blockquote><div>That basically says " (an MPI implementor) creates a multi-element pvar (i.e., pvar with count > 1)"<br>
<br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>Slide 3: "Problem: But how do you know which array slot maps to which underlying Linux device?</div><div>  Solution: the btl_usnic_devices state performance variable."</div>
<div><br></div></blockquote><div>I suppose "YOU"  in the problem is an MPI_T user, for example, a tool developer. The question is distilled into "the user wants to know names of elements in a multi-element pvar". </div>
<div>My solution is to provide the user with a new routine <span style="font-size:13px;font-family:arial,helvetica,sans-serif">MPI_T_pvar_get_subnames. </span><span style="font-family:arial,helvetica,sans-serif;font-size:13px">Whether these names are shared or duplicated between pvars, the user doesn't need to know.  It is an MPI implementation issue. </span><span style="font-family:arial,helvetica,sans-serif">We already have name for pvar. That is why I use "subnames" for names of elements in a such a pvar.</span></div>
<div><br></div><div>Is my understanding of the problem correct?</div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">--Junchao Zhang</div></div>
<br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 4:17 PM, Jeff Squyres (jsquyres) <span dir="ltr"><<a href="mailto:jsquyres@cisco.com" target="_blank">jsquyres@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm afraid I didn't understand your prior proposal; I hoped there would be more explanation.<br>
<br>
Perhaps you can make up several slides to explain what you're proposing with some pictures and diagrams for tomorrow.  E.g., what is your *exact* definition of a "subname"?  And how would I apply a set of common subnames to N different pvars (hopefully without replicating them N times)?<br>

<div class="HOEnZb"><div class="h5"><br>
<br>
On Nov 13, 2013, at 5:02 PM, Junchao Zhang <<a href="mailto:jczhang@mcs.anl.gov">jczhang@mcs.anl.gov</a>> wrote:<br>
<br>
> After reading mails in this thread, it seems we just want to get names of elements in a pvar, right?<br>
> So, why do not provide this functionality directly.<br>
>   // Return true or false in has_subnames.<br>
>   MPI_T_pvar_has_subnames(session, handle, int has_subnames);<br>
>   // If has_subnames, use this function to get their names<br>
>   MPI_T_pvar_get_subnames(session, handle, char * subnames[], int lens[]); // Very like the newly proposed MPI_T_pvar_read_str()<br>
><br>
> --Junchao Zhang<br>
><br>
> On Tue, Nov 12, 2013 at 4:09 PM, Schulz, Martin <<a href="mailto:schulzm@llnl.gov">schulzm@llnl.gov</a>> wrote:<br>
><br>
> On Nov 12, 2013, at 12:51 PM, "Jeff Squyres (jsquyres)" <<a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a>><br>
>  wrote:<br>
><br>
> > On Nov 11, 2013, at 7:03 PM, "Schulz, Martin" <<a href="mailto:schulzm@llnl.gov">schulzm@llnl.gov</a>> wrote:<br>
> ><br>
> >>>> I think it would be better to programmatically express such relationships -- i.e., something new for MPI-4.<br>
> >><br>
> >> I agree with that, but I see it more as an MPI 3.1 feature. Is it really a major concept?<br>
> ><br>
> > I thought it was "more" than a minor/bug fix concept... and therefore should wait until 4.<br>
><br>
> We need to finally discuss and decide that (as the forum) - this will definitely be on the agenda in December.<br>
><br>
> >>> Er... I don't understand.  Why can't the enum strings change?  I think they can change at any time.<br>
> >><br>
> >> 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.".<br>

> ><br>
> > Mmm.  Yes.  This *implies* that they don't change, but one could argue different meanings of "fixed set".<br>
><br>
> I know, this is ambiguous.<br>
><br>
> ><br>
> >> 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.<br>
> ><br>
> > It sounds like you are introducing a new requirement, then: you want non-mutable strings, but the ability to have things change over time (e.g., new NICs added or old NICs dropped).<br>
><br>
> Well, I think we have two separate issues here:<br>
> - Should strings be allowed to change? In particular, should we allow enumerations to change on the fly? I think the answer to this should be no, since this would create race conditions and it would prevent tools from caching any data (that's why we did it for the variable metadata and for the types it seems even more relevant)<br>

> - Do we need a mechanism to describe changing variable arrays? This is more a requirement question - how is this in your case? Will you support changing number of NICs and how are you planning on doing that?<br>
><br>
> ><br>
> >>> 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."<br>

> >><br>
> >> Yes, but the count can change when you get a new handle.<br>
> ><br>
> > That would be fairly hellish for an implementation: session/handle X has N values, but simultaneously, session/handle Y of the same pvar -- which just happened to be created after session/handle X -- has M values.<br>

> ><br>
> > Meaning: the implementation has to track two entirely different views/counts of the same pvar.<br>
><br>
> Well, wouldn't that be up to the implementation? If it doesn't make sense for a particular case, then an MPI can always return the same count. I agree, if an MPI does do it that way, it won't be easy.<br>

><br>
> ><br>
> >> 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.<br>
> ><br>
> > ...which is *any* variable, right?<br>
><br>
> Yes - what I meant was that if there is a variable that a particular MPI implementation always decides to return 1 for, then you will probably never need a matching enumeration variable. However, just because it returns 1 once, it doesn't mean that it is guaranteed that it will stay that way for the rest of the run or during the next run. Hence, matching enumeration variables make sense even for variables that have a count of 1.<br>

><br>
> Martin<br>
><br>
><br>
> ><br>
> > --<br>
> > Jeff Squyres<br>
> > <a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>
> > For corporate legal information go to: <a href="http://www.cisco.com/web/about/doing_business/legal/cri/" target="_blank">http://www.cisco.com/web/about/doing_business/legal/cri/</a><br>
> ><br>
><br>
> ________________________________________________________________________<br>
> Martin Schulz, <a href="mailto:schulzm@llnl.gov">schulzm@llnl.gov</a>, <a href="http://people.llnl.gov/schulzm" target="_blank">http://people.llnl.gov/schulzm</a><br>
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA<br>
><br>
><br>
><br>
> _______________________________________________<br>
> mpiwg-tools mailing list<br>
> <a href="mailto:mpiwg-tools@lists.mpi-forum.org">mpiwg-tools@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools</a><br>
><br>
> _______________________________________________<br>
> mpiwg-tools mailing list<br>
> <a href="mailto:mpiwg-tools@lists.mpi-forum.org">mpiwg-tools@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools</a><br>
<br>
<br>
--<br>
Jeff Squyres<br>
<a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>
For corporate legal information go to: <a href="http://www.cisco.com/web/about/doing_business/legal/cri/" target="_blank">http://www.cisco.com/web/about/doing_business/legal/cri/</a><br>
<br>
_______________________________________________<br>
mpiwg-tools mailing list<br>
<a href="mailto:mpiwg-tools@lists.mpi-forum.org">mpiwg-tools@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools</a><br>
</div></div></blockquote></div><br></div>