[mpiwg-tools] Tools topics meeting reminder: Jan 19, 2017

Thu Feb 2 05:19:38 CST 2017

Keep in mind that I proposed a *tuple*, not a single value.  You may be assuming we can split up the uint64_t into a tuple -- but I just wanted to make sure we'r talking about the same thing.

The tuple was (vendor ID, part ID, event ID).  I think you're mainly asking about the vendor ID part.

In libibverbs, such vendor IDs are typically the Organization Unique Identifier (https://en.wikipedia.org/wiki/Organizationally_unique_identifier and http://standards-oui.ieee.org/oui/oui.txt).

I.e., we could just leverage this existing IEEE standard -- no need to print all this stuff in the MPI standard itself.

> On Feb 1, 2017, at 3:24 AM, Marc-Andre Hermanns <hermanns at jara.rwth-aachen.de> wrote:
> 
> Hi Martin, Hi Jeff,
> 
> my apologies for taking so long to reply.
> 
> As far as I understand and remember we discussed these universal IDs
> in both contexts: (1) source ids and (2) event types.
> 
> Such an ID would allow a tool to cast a pointer to an info struct to a
> specific known struct revealing additional information.
> 
> In context of Martin's comment on easy integration with the existing
> API, I could imagine a call like
> 
> int
> MPI_T_event_get_uid(int index, uint64_t* uid);
> 
> 'uid' being the short form of "universal id". It would be easy to
> provide such a call for the other parts (performance/control
> variables) of MPI_T as well.
> 
> There are some questions arising from this vendor prefixed ID:
> 1) Which entity issues the prefixes to ensure we don't have duplicates?
> 2) How would a vendor apply for/request a prefix?
> 3) Where would the issued prefixes be listed? In the standard?
> 4) Would the rest of the ID be free for the vendor to use, or would we
> need to reserve some bits?
> 
> We should use this weeks call to discuss this further.
> 
> Cheers,
> Marc-Andre
> 
> 
> On 22.01.2017 10:55, Schulz, Martin wrote:
>> Hi Jeff,
>> 
>> Don’t get me wrong - I wasn’t proposing to push this onto the long bench and do it after MPI-4. There is no reason to not bring this up in time for MPI 4 or even develop it together. I was just suggesting to decouple this from the actual events ticket for two reason:
>> - I think the events part is fairly far along and probably easily accepted and I was suggesting to not push it out because of this
>> - We need a clean retrofit solution anyway to make it work for variables - we can the use it for events as well.
>> 
>> At the end, this is up to Marc-Andre since he is doing the work :)
>> 
>> Martin
>> 
>> 
>> 
>>> On Jan 20, 2017, at 6:41 PM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:
>>> 
>>> My $0.02: we know that there are limitations with the way we've been approaching this stuff for years (over specifying, e.g. PERUSE, which got shot down/shunned, and under specifying leads to tools without any semantic information and implementations that are not incentivized to do anything because the Forum doesn't like "creative" uses of the API, even if they give semantic information to the tools [who are asking exactly for this semantic information] -- e.g., usNIC BTL use of MPI_T variables on a per-interface basis).
>>> 
>>> Why not learn from these limitations and propose something better?
>>> 
>>> My point: if we're going to do this, do it right.  Let's not have more buyer's remorse after MPI-4 because the new API (still) doesn't give tools any rich and/or semantic information.
>>> 
>>> ----
>>> 
>>> Keep in mind that I proposed two different ideas:
>>> 
>>> 1. The idea of identifying event sources by a (vendor ID, part ID, source ID) tuple
>>> 2. The idea of a sanctioned extension mechanism
>>> 
>>> Note that neither of these are new ideas; they're borrowed from best practices that just happen to be (just barely) outside of the realm of MPI.
>>> 
>>> They're still best practices, though.
>>> 
>>> 
>>>> On Jan 20, 2017, at 12:03 AM, Martin Schulz <schulzm at llnl.gov> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I was thinking about today’s discussion on the tools call and since I won’t be able to join in two weeks, I thought I’d send a follow-up to start a discussion:
>>>> 
>>>> I like Jeff’s ideas to provide cross-platform events that are keyed using a vendor ID (or sets of IDs). As Jeff mentioned, it would be cool to see common events in different MPIs if they are built on the same underlying layer. 
>>>> 
>>>> Listing to the discussion today, though, I think this would face quite some controversy in the forum and makes the overall problem quite a bit bigger. Also, this functionality seems useful for control and performance variables, for the same reason, and hence it would be good to look for a solution that can also be retrofitted to these variables. A second set of get info calls that translate an MPI specific event/variable ID to a vendor ID could be one option (but just shooting off the hip right now).
>>>> 
>>>> I’d therefore suggest to separate the two issues - one ticket to add events in the style that we have already (which seems to be quite acceptable to the forum, at least there weren’t many negative comments) - and then a second ticket on adding vendor IDs to all three MPI_T concepts (again in the same style). This could help MPI_T events in its discussion in the forum and potentially get it passed sooner and it would give us consistency between the three MPI_T concepts. 
>>>> 
>>>> What do you all think about this?
>>>> 
>>>> Thanks!
>>>> 
>>>> Martin
>>>> 
>>>> 
>>>>> On Jan 19, 2017, at 1:15 AM, Marc-Andre Hermanns <hermanns at jara.rwth-aachen.de> wrote:
>>>>> 
>>>>> Dear all,
>>>>> 
>>>>> This is the gentle reminder for this week's call with a session on
>>>>> *Performance Tools*:
>>>>> 
>>>>> Thursday Jan 19, 2017 11 a.m. Eastern Time (*today*)
>>>>> 
>>>>> Here is the webex link:
>>>>> 
>>>>> https://cisco.webex.com/ciscosales/j.php?MTID=m0fb3e4a68162bff5874849e4700b806a
>>>>> 
>>>>> Agenda:
>>>>> - MPI_T events
>>>>> 
>>>>> Cheers,
>>>>> Marc-Andre
>>>>> -- 
>>>>> Marc-Andre Hermanns
>>>>> Jülich Aachen Research Alliance,
>>>>> High Performance Computing (JARA-HPC)
>>>>> Jülich Supercomputing Centre (JSC)
>>>>> 
>>>>> Wilhelm-Johnen-Str.
>>>>> 52425 Jülich
>>>>> Germany
>>>>> 
>>>>> Phone: +49 2461 61 2509 | +49 241 80 24381
>>>>> Fax: +49 2461 80 6 99753
>>>>> www.jara.org/jara-hpc
>>>>> email: hermanns at jara.rwth-aachen.de
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> mpiwg-tools mailing list
>>>>> mpiwg-tools at lists.mpi-forum.org
>>>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools
>>>> 
>>>> ________________________________________________________________________
>>>> Martin Schulz, schulzm at llnl.gov, http://scalability.llnl.gov/
>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> mpiwg-tools mailing list
>>>> mpiwg-tools at lists.mpi-forum.org
>>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools
>>> 
>>> 
>>> -- 
>>> Jeff Squyres
>>> jsquyres at cisco.com
>>> 
>>> _______________________________________________
>>> mpiwg-tools mailing list
>>> mpiwg-tools at lists.mpi-forum.org
>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools
>> 
>> 
>> 
>> _______________________________________________
>> mpiwg-tools mailing list
>> mpiwg-tools at lists.mpi-forum.org
>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools
>> 
> 
> -- 
> Marc-Andre Hermanns
> Jülich Aachen Research Alliance,
> High Performance Computing (JARA-HPC)
> Jülich Supercomputing Centre (JSC)
> 
> Wilhelm-Johnen-Str.
> 52425 Jülich
> Germany
> 
> Phone: +49 2461 61 2509 | +49 241 80 24381
> Fax: +49 2461 80 6 99753
> www.jara.org/jara-hpc
> email: hermanns at jara.rwth-aachen.de
> 
> 
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools

-- 
Jeff Squyres
jsquyres at cisco.com