Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Richard Graham (rlgraham_at_[hidden])
Date: 2007-10-09 04:02:58


One of the assumptions about the MTL¹s is that only a given MTL can handle
the message
 matching for communications. This is done to accommodate mpi-like network
stack that
 also handle the MPI message matching, which often do not expose their
internal data
 structures used for matching. Open MPI¹s point-to-point selection
currently forces the
 choice of single pml, and if CM is chosen, only a single MTL. Under those
constraints
 any MTL internal structs can be kept within the scope of the MTL, w/o
polluting the global
 name-space.

Rich

On 10/8/07 5:09 PM, "Sajjad Tabib" <stabib_at_[hidden]> wrote:

>
> Hi,
>
> I'm implementing a new MTL component that uses message queues to keep track of
> posted and unexpected messages. I intended to do this by creating two global
> queues, one for posted and one for unexpected, until I found that the portals
> MTL uses a different approach in their queue implemenation. The portal code
> uses handles to the queues from inside their mca_mtl_portals_module_t to post
> messages. I couldn't help but wonder, why are the queue handles here? What are
> the design implications of defining these handle queues in this module struct
> rather than globally defining them?
> I'm an Open MPI newbie and sort of confused on the modular approach taken here
> and was hoping somebody could point out the pros and the cons of the two
> approaches. I guess my next question would be: In general, what would you put
> into a module struct and what wouldn't you?
> I will appreciate any pointers that you could give me to help me understand
> this concept.
>
> Thanks in advance,
>
> Sajjad Tabib
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel