Attendees:
Lloyd Lewins Hughes
John Hagendorn NIST
Dennis Cottel NRaD
Thomas Robey Khoral Research
Anna Rounbehler SKY Computers
Arkady Kanevsky MITRE
Ron Brighwell Sandia National Labs
Robert Babb U. of Denver
Harish Nag Intel,SSPD
Shane Hebert MSU
Darren Sanders U. of Houston
The following topics were discussed.
1. The dates of the February MPI/RT meeting were discussed.
Tentatively, the meeting will be held at NRAD in San Diego, Feb 12, 13.
2. A list of functionality should be cross checked between MPI-2.0 and
MPI/RT. Many elements of MPI-2.0 that MPI/RT relied on
are changing or moving outside MPI-2 into the JOD.
Topics for review for next meeting may include:
Threads
Generalized requests handlers
MPI Progress rules
Caching on attributes
Datatypes
Error reporting
Naming functions
check againist MPI rules
check C++ bindings to be sure conventions match
3. References to the functions MPI_WTIME and MPI_WTICK were accidentally
changed in the RT chapter to MPIRT. This should be changed back.
Provide a discussion on the difference between MPI/RT clock parameters
and MPI clock parameters and why.
Initializing Channels
------------------------
4. The old proposal that consist of deleting one version of
the channel initialization and renaming the other one.
Vote was taken to delete MPIRT_CHANNEL_INIT and rename
MPIRT_BUFPOOL_CHANNEL_INIT to MPIRT_CHANNEL_INIT.
The vote was passed unanimously.
Add more advice to implementors on sharing buffer pools among
channels.
Clarify the legality of the zero length messages.
5. A proposal was made by Tom of Khoral research to eliminate the delete
and modify functions on page 19. A new operation was proposed that combines
initialize, modify and delete of channels.
A vote was taken in favor of Tom writing up his proposal.
Rationale: What happens when all channels that have been requested to be
initialized, do not get successfully initialized? Releasing and
regrabbing resources should not be decoupled. This is currently
the model for modify channel operation.
However if an application would like to release some resources
from the existing channels so they can be used for establishing
new channels there is no atomic operation to do it now.
Hence, application required to release resource first
and only then ask for new channels. By that time resources may be gone.
If one end of the channel fails, error messages may be misleading.
There was discussion on the result of init operation.
Should the channel init philosophy be all or nothing?
The vote was taken to change operation completion of init
to be analogous to modify and it was tabled.
Voted to reconsider Tom's proposal after thinking about ramifications
at the February meeting.
(Haresh agreed to write a new version of the proposal since Tom
will not be able to attend.)
6. An orthogonal issue was raised with respect to the items that
the user should be allowed to modify for the channels
(currently: bufpools, error and QOS).
Also, clarification is needed as to whether the single channel modify
ONLY allows QOS to be modified.
A vote was taken to NOT remove the modify for a single channel
until all the details of the combined init/modify/delete operation
are settled.
7. Clarification is needed about the matching order of two endpoints
of a channel. If the same initialization operation establishes
more than one channel between the same ranks of the communicator
the matching order has to be defined.
8. The issue of allowing channels from a rank to itself was discussed.
The vote was taken and it was decided that we should allow to create
channels to itself (loops) with matching order of #7 ensuring
that the channel ends properly match.