<div>Jie,</div>
<div>in addition the only guarantee that transport standards provide are</div>
<div>at completion reap time. The state of the user buffer prior to that is opaque.</div>
<div>Some vendors may provide stronger semantic but it is outside the scope</div>
<div>of both IB and iWARP transports.</div>
<div>Cheers,</div>
<div>Arkady<br><br></div>
<div class="gmail_quote">On Wed, Apr 1, 2009 at 11:52 AM, Caitlin Bestler <span dir="ltr"><<a href="mailto:caitlin.bestler@gmail.com">caitlin.bestler@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">On Tue, Mar 31, 2009 at 11:41 PM, Jie Cai <<a href="mailto:Jie.Cai@cs.anu.edu.au">Jie.Cai@cs.anu.edu.au</a>> wrote:<br>> Understood now. A further question is here again.<br>><br>> To implement software level acknowledgment to inform initiator that data<br>
> has been available for remoter, is that possible to use a busy loop at<br>> remote<br>> side to detect the last element of transferring has appear in the memory.<br>><br>> Or remoter has to wait for the event of recv matching initiator's send, then<br>
> send a message back to initiator as a acknowledgment?<br>><br><br></div>There are two issues when spinning on a remote memory update.<br><br>The first is that packets may be received and processed out of order,<br>
especially for iWARP. Therefore the fact that the last byte has been<br>received and placed does not guarantee that the prior packets have<br>been received and placed.<br><br>More importantly, the order in which updates become visible to a<br>
specific software thread can make the order of updates unpredictable<br>to the application.<br><br>When delivering a completion the Provider is responsible for dealing<br>with both of these problems. So when you reap a completion from the<br>
CQ, the operation it represents (and all prior operations) are complete.<br>There are no gaps in received packets, nothing is still sitting on an<br>Adapter buffer waiting to be placed in host memory.<br><br>If your application does not want to block you can consider polling<br>
the cq whether than enabling notifications. But polling memory locations<br>directly should only be done when you're willing to have bus/adapter<br>specific dependencies. You working code might stop working when<br>your network changes, or you install a new Adapter that has a different<br>
strategy for optimizing its writes over the PCIe bus.<br></blockquote></div><br><br clear="all"><br>-- <br>Cheers,<br>Arkady Kanevsky<br>