Thanks to all of you who joined the webex for the discussion. Short version of the results:
- PSM and OFI MTL maintainers said that they will look into "promoting" themselves to be a PML. They didn't think it would be too hard (but aren't promising anything yet). - Portals MTL maintainers said they need to investigate some more. Their concern was that CM was providing a nice neutral abstraction layer that shielded them from main OMPI core data structures; it would be a shame to lose that shielding. That being said, if portals is the only MTL left, the portals MTL maintainers would likely become the CM maintainers, too, and therefore the shielding would effectively be gone. Fair point. Portals MTL maintainers need to investigate more. - PSM and OFI MTL maintainers said that they would investigate writing OSC components (but are promising nothing). I suggested that they talk with/work with Nathan; he said he might be able to abstract out some common functionality/code (perhaps into osc/base?) that OSC components could jointly utilize. TBD. - MXM has no current plans to implement an OSC component. - Portals already has an OSC component. Conclusions: 1. Not clear yet on whether CM will survive in the long term. 2. There is no need for one-sided extensions to the MTL interface. > On Jan 28, 2015, at 6:25 PM, Jeff Squyres (jsquyres) <[email protected]> > wrote: > > MTL authors -- > > We had *some* discussion of MTL issues this afternoon in the room, but need > your input (since most of you are not here). Here's what we'd like to talk > about tomorrow (and we realize you might not have answers for this tomorrow). > > Short version: based on Mellanox's experience, why not ditch the CM PML and > have all current MTLs move up to be PMLs? > > More detail: > > We all know that Mellanox moved their MXM MTL up to be a PML. The short > version of "why did they do this?" is because CM really added no value for > MXM. Literally, all it did was add overhead: > > 1. translate some OMPI data structures to a neutral/CM data structure > 2. which was then translated into the MXM data structures > 3. then call MXM > > So why not chop out one of those layers: > > 1. translate OMPI data structures into MXM data structures > 2. then call MXM > > Taking a crass look at the existing MTLs, we wonder if it would be worthwhile > to do the same thing for all of them. It doesn't seem (to us) that it would > be a lot of work -- the PML and MTL interfaces are quite similar. And there > could be message rate improvements for those MTLs-turned-PMLs, just like it > did for MXM/yalla. > > *If* this is a good assumption -- that MTLs should all become PMLs -- then > MPI one-sided operations become the next logical question. I.e., what > happens when you call MPI_PUT / MPI_GET / etc.? > > Right now, you'll end up using the osc/pt2pt component, which will use PML > calls to effect MPI RMA functionality over the PML interface. Which is fine, > and will work correctly in all cases. > > However, MTL-turned-PML authors will then have the option of writing an > osc/YOUR_COMPONENT for doing optimized MPI-one-sided operations on your > network. > > This is what we would like to discuss with you tomorrow. Tell us that this > idea is crazy, or that it's ok, or that you need to think about it, ...etc. > Let's chat. > > -- > Jeff Squyres > [email protected] > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > devel mailing list > [email protected] > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2015/01/16836.php -- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
