On Mar 7, 2010, at 12:59 PM, Ralph Castain wrote:
> > Quick question about this. We now have an OPAL level progress
> thread, which enables the machinery at the OPAL level.
> Unfortunately, this doesn't say anything about what the MPI level
> will do?
> That is correct and has always been the case. The OPAL progress
> thread only indicates that opal_progress is being called via a
> separate thread. Currently, turning "on" the opal progress thread
> automatically turns "on" opal thread support and enables MPI thread
> multiple. However, the BTLs may or may not be involved (see below).
How about calling it --enable-opal-event-progress-thread, or even --
> This RFC is solely to change the configure option names to remove
> the badly overloaded and confusing --enable-mpi-threads
> At the moment, the BTLs already use their own progress threads and
> do -not- utilize the OPAL progress thread. Why the various BTL
> developers chose to do this is unknown to me and essentially
> irrelevant to this RFC. What the BTL developers may want to do is
> review the reasons behind this design decision. As I understand it,
> there was consideration of this question, and it was a made decision
> (as opposed to a simple oversight) to have BTL-specific progress
> threads instead of relying on the OPAL progress thread.
The openib BTL can have up to 2 progress threads (!) -- the async
verbs event notifier and the RDMA CM agent. They really should be
consolidated. If there's infrastructure to consolidate them via opal
or something else, then so much the better...
For corporate legal information go to: