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" <sta...@us.ibm.com> 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 > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
