[mpiwg-tools] Open MPI pvar scheme

Wed Nov 13 17:13:35 CST 2013

 Let me comment on the problem in your slides of last teleconf:

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.
  Solution: have each performance variable return an array of values; one
for each underlying network device"

That basically says " (an MPI implementor) creates a multi-element pvar
(i.e., pvar with count > 1)"

Slide 3: "Problem: But how do you know which array slot maps to which
underlying Linux device?
  Solution: the btl_usnic_devices state performance variable."

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".
My solution is to provide the user with a new routine MPI_T_pvar_get_subnames.
Whether these names are shared or duplicated between pvars, the user
doesn't need to know.  It is an MPI implementation issue. We already have
name for pvar. That is why I use "subnames" for names of elements in a such
a pvar.

Is my understanding of the problem correct?

--Junchao Zhang

On Wed, Nov 13, 2013 at 4:17 PM, Jeff Squyres (jsquyres) <jsquyres at cisco.com
> wrote:

> I'm afraid I didn't understand your prior proposal; I hoped there would be
> more explanation.
>
> 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)?
>
>
> On Nov 13, 2013, at 5:02 PM, Junchao Zhang <jczhang at mcs.anl.gov> wrote:
>
> > After reading mails in this thread, it seems we just want to get names
> of elements in a pvar, right?
> > So, why do not provide this functionality directly.
> >   // Return true or false in has_subnames.
> >   MPI_T_pvar_has_subnames(session, handle, int has_subnames);
> >   // If has_subnames, use this function to get their names
> >   MPI_T_pvar_get_subnames(session, handle, char * subnames[], int
> lens[]); // Very like the newly proposed MPI_T_pvar_read_str()
> >
> > --Junchao Zhang
> >
> > On Tue, Nov 12, 2013 at 4:09 PM, Schulz, Martin <schulzm at llnl.gov>
> wrote:
> >
> > On Nov 12, 2013, at 12:51 PM, "Jeff Squyres (jsquyres)" <
> jsquyres at cisco.com>
> >  wrote:
> >
> > > On Nov 11, 2013, at 7:03 PM, "Schulz, Martin" <schulzm at llnl.gov>
> wrote:
> > >
> > >>>> 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?
> > >
> > > I thought it was "more" than a minor/bug fix concept... and therefore
> should wait until 4.
> >
> > We need to finally discuss and decide that (as the forum) - this will
> definitely be on the agenda in December.
> >
> > >>> 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.".
> > >
> > > Mmm.  Yes.  This *implies* that they don't change, but one could argue
> different meanings of "fixed set".
> >
> > I know, this is ambiguous.
> >
> > >
> > >> 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.
> > >
> > > 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).
> >
> > Well, I think we have two separate issues here:
> > - 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)
> > - 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?
> >
> > >
> > >>> 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.
> > >
> > > 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.
> > >
> > > Meaning: the implementation has to track two entirely different
> views/counts of the same pvar.
> >
> > 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.
> >
> > >
> > >> 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.
> > >
> > > ...which is *any* variable, right?
> >
> > 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.
> >
> > 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
> >
> >
> >
> > _______________________________________________
> > mpiwg-tools mailing list
> > mpiwg-tools at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
> >
> > _______________________________________________
> > mpiwg-tools mailing list
> > mpiwg-tools at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20131113/ce307cf7/attachment-0001.html>