<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Good points! RMA interfaces should do nothing to prevent utilizing a high message rate (or low overhead communication) that the underlying hardware may offer. To ensure this happens, there should always be a unrestricted path (lets call it this for now, people have called it a "thin layer", "direct access") to the network. <div><br></div><div>This means, despite the fact the the RMA interface has features that abstract out complexity by providing useful characteristics such as ordering and atomicity, it (the RMA interface) should always have this unrestricted, close to the heart of the hardware, path. To achieve this, the unrestricted path should not require any book keeping (from implementation perspective) in relation to the feature-rich path or vice-versa.  </div><div><br></div><div>I believe this is what we have demonstrated with the example interfaces hence the null set isn't the case here :-). I will distribute an example implementation very soon so people can get a feel.</div><div><br></div><div><div>---</div><div><span style="font-size:10pt;font-family:'Verdana','sans-serif'">Vinod Tipparaju ^ http://ft.ornl.gov/~vinod ^ 1-865-241-1802</span><br><br><br><br>> From: keith.d.underwood@intel.com<br>> To: mpi3-rma@lists.mpi-forum.org<br>> Date: Mon, 31 Aug 2009 16:17:28 -0600<br>> Subject: Re: [Mpi3-rma] MPI3 RMA Design Goals<br>> <br>> There has been stunning silence since this email, so I will go ahead and toss out a thought...<br>> <br>> In the draft design goals, I don't see two issues that I see as key.  The first is "support for high message rate/low overhead communications to random targets".  As best I can tell, this is one of the key places were the existing one-sided operations are perceived as falling down for existing customers of SHMEM/PGAS.   The second is "elimination of the access epoch requirement".  This one may be, um, more controversial, but I believe it is part and parcel with the first one.  That is, the first one is not that valuable if the programming model requires an excessive amount of access epoch opens and closes just to force the global visibility of the operations.  Unfortunately, the intersection of this solution space with the solution space for the current draft design goal #5 (support non-cache-coherent and heterogeneous environments) may be the null set...  I will hold out hope that this isn't the case ;-)<br>> <br>> Keith    <br>> <br>> > -----Original Message-----<br>> > From: mpi3-rma-bounces@lists.mpi-forum.org [mailto:mpi3-rma-<br>> > bounces@lists.mpi-forum.org] On Behalf Of William Gropp<br>> > Sent: Wednesday, August 05, 2009 12:37 PM<br>> > To: mpi3-rma@lists.mpi-forum.org<br>> > Subject: [Mpi3-rma] MPI3 RMA Design Goals<br>> > <br>> > I've added versions of the RMA design goals that we discussed at the<br>> > Forum meeting last week to the wiki page for our group (<br>> > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage<br>> >   ).  This is a draft; lets discuss these.  Also, feel free to add to<br>> > the discussion, particularly in the background section.<br>> > <br>> > Bill<br>> > <br>> > William Gropp<br>> > Deputy Director for Research<br>> > Institute for Advanced Computing Applications and Technologies<br>> > Paul and Cynthia Saylor Professor of Computer Science<br>> > University of Illinois Urbana-Champaign<br>> > <br>> > <br>> > <br>> > <br>> > _______________________________________________<br>> > mpi3-rma mailing list<br>> > mpi3-rma@lists.mpi-forum.org<br>> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma<br>> <br>> _______________________________________________<br>> mpi3-rma mailing list<br>> mpi3-rma@lists.mpi-forum.org<br>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma<br></div></div></body>
</html>