<html><body>
<p>Hi Jeff<br>
<br>
I do not understand the need for two distinct origin side operations if you will assume the agency infrastructure must always be standing by ready to be activated. <br>
<br>
The MPI implementation will be able to determine at the origin side if the parameters passed into a complex RMA fit the capabilities of its NIC. It can decide whether to use the intrinsic NIC mode or the software agent mode.  If it has a NIC that does integer accumulate but not floating point accumulate, the implementation can pick between NIC mode and agent mode. When a new NIC that does floating point accumulate comes along, the implementation can exploit it with no need for application rewrite.<br>
<br>
On the other hand, the RAW RMA can be used by by applications that want to exploit NIC capabilities that are widely available today and do not want to drag in overheads for an agent waiting on the sidelines. An agent that they may know will never be needed. If someday in the future the typical NIC has certain additional capabilities we can add a richer RAW operation to the MPI standard.<br>
<br>
Can you explain to me what you expect to have always available as a software agent that will be there at no significant cost in memory or harm to performance of non-RMA operations?<br>
<br>
Are you thinking we need two distinct routines just to avoid a couple "if" tests to decide inside libmpi whether to use NIC based or agent based RMA?<br>
<br>
             Dick <br>
<br>
Dick Treumann  -  MPI Team           <br>
IBM Systems & Technology Group<br>
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846         Fax (845) 433-8363<br>
<br>
<br>
<img width="16" height="16" src="cid:1__=0ABBFCA0DFE246848f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Jeff Hammond ---09/16/2009 04:37:33 PM---I was having the same thoughts during my hideous commute tod"><font color="#424282">Jeff Hammond ---09/16/2009 04:37:33 PM---I was having the same thoughts during my hideous commute today. Clearly, future systems may have ver</font><br>
<br>

<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFCA0DFE246848f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">From:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFCA0DFE246848f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">Jeff Hammond <jeff.science@gmail.com></font></td></tr>

<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFCA0DFE246848f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">To:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFCA0DFE246848f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">"MPI 3.0 Remote Memory Access working group" <mpi3-rma@lists.mpi-forum.org></font></td></tr>

<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFCA0DFE246848f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">Date:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFCA0DFE246848f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">09/16/2009 04:37 PM</font></td></tr>

<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFCA0DFE246848f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">Subject:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFCA0DFE246848f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">Re: [Mpi3-rma] non-contiguous support in RMA & one-sided     pack/unpack (?)</font></td></tr>

<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFCA0DFE246848f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">Sent by:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFCA0DFE246848f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">mpi3-rma-bounces@lists.mpi-forum.org</font></td></tr>
</table>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><snip></tt><br>
<tt><br>
I'm not sure I understand all this talk about assertions upon<br>
initialization, since I was hoping that Raw_xfer and general-purpose<br>
xfer (Gen_xfer) would both always be available but that the former<br>
would be much faster in certain contexts, since implementing the Raw<br>
version close to hardware doesn't require much work and would not<br>
interfere with how Gen_xfer operates.  Am I missing something?<br>
<br>
</tt><tt><snip><br>
</tt><br>
<br>
</body></html>