Message Queue Manager

Discussion of Collective Communications

For convenience, these are expressed as questions and possible answers. Working group members should refer to items by number in commenting or suggesting alternate approaches.

A. Standardizing our terminology (among the working group)

We need to be careful about terms, since whatever design is settled on must be applicable to collective communications not just in MPI, but in other libraries as well. Our decisions should cover at least MPI, PVM, and NX (and others, if necessary to ensure generality).

The original suggestion referred to "group id", based on Cherri Pancake's notes from early discussions with users about how collective communications might be represented. (However, those users only had experience with PVM, NX, and nCUBE message-passing.) They indicated that they established relatively few groups, and that they would want to be able to filter according to group membership, just as MQM supports filtering by message tag.
Rusty Lusk pointed out that:
The Web page refers to group ids where it really should be referring to communicators. There can be multiple communicators attached to the same group, and since all communication takes place in communicators, that is the more important concept. (There can't be two different groups for the same communicator.) Communicator identifiers are currently being discussed in the MPI-2 Forum. They do not exist as a concept in MPI as it currently stands.
Bob Dilly responded:
We are working on the premise that scoping by communicator is the first priority. That is, pick a communicator and look around at that level. We talked about group as a filter (I believe) as you suggested. I think these make sense for MPI. How to represent them meaningfully is another story....
Rusty Lusk responded:
The problem here is that a common use of communicators is to use multiple communicators having the same group.
Issues to discuss:
- Is it true that we are all talking about adding just one new level of filtering (an approach that certainly suffices for libraries other than MPI)? If not, are there practical examples of when a user would really need to filter at two different levels?
- What does Bob mean about "scoping by communicator" as opposed to "using group as a filter"? Can he provide some practical examples?
- Is group or communicator the right element for the filter? Is this affected by the fact that communicator IDs do not exist in the current MPI spec?

B. Changes to the Overview Dialog

PROPOSED: For implementations accommodating collective communication, a new radio grouping will be added to the bottom of the current list (in process subset displays, this will appear as a list button instead of radio lights). Metausers will be asked to validate/critique the change and to select the precise wording as well as the default setting.
Based on early working group discussions with users, the following list is offered as an initial strawman for representing the general categories of collective communications:
```
    All collective operations in progress (default)
	Broadcasts/scatters only
	Reductions/gathers only
	Don't show collective operations
	
```
Issues to discuss:
- Is this the only change that will be necessary?
- Should we present the metausers with tentative identification of which routines will be mapped to which categories? If so, should we show PVM, NX, and MPI? Others?

C. Changes to the Filter Dialog

PROPOSED: For implementations accommodating collective communication, a new list of group/communicator IDs will be added to the right of the current message tag list. The two lists will scroll independently. Metausers will be asked to validate/critique the change.
Issues to discuss:
- Is this the only change that will be necessary?

D. Changes to the Process-Level Display

PROPOSED: For implementations accommodating collective communication, queue entries will have a group/communicator field as well as message tag and source/destination. Metausers will be asked to validate/critique the change and to specify the location of the new field (relative to the two existing fields).
Issues to discuss:
- Is this the only change that will be necessary?
- Should there be an option to include two or more new fields here (e.g., communicator as well as group)? If so, under what circumstances should it be recommended?

Post comments to the working group, ptools-mqm@ptools.org.