Sorry about the delay in joining in on this discussion. This is a very
good proposal. A couple of questions:
1. I assume the motivation for defining MPI_ENDPOINTS is to allow the
implementation to tell the user how many physical connection resources
it can use (sockets or some other network connection endpoints).
However, it is possible for multiple MPI endpoints to share the same
physical network endpoints. This is obviously inefficient since it'll
bring back all the locking overheads for shared resources, but probably
not impossible.
My question is -- do we want to explicitly restrict users from creating
more end points than the available physical resources? Or is it
beneficial to allow users have any number of MPI endpoints, but have
MPI_ENDPOINTS specify how many it can "efficiently" support?
2. I didn't quite get the motivation for this statement on page 6: "At
each process, the endpoint with rank 0 in MPI_COMM_PROCESS is also an
endpoint in MPI_COMM_WORLD". Obviously, we want *some* endpoint to be a
part of COMM_WORLD, but can't the user figure this out at runtime? Or is
this just for simplicity (which is a good reason, but I just wasn't sure)?
Thanks,
-- Pavan
--
Pavan Balaji
http://www.mcs.anl.gov/~balaji
|
![[Flag]](../../../../../images/flag-us.gif){kind=small}