<div>Correct.</div>
<div>The only guarantee you have when you get Send completion is that </div>
<div>you can reuse the buffer and message has been sent.</div>
<div>It does not guarantee that message is in recv buffer.</div>
<div> </div>
<div>For some transports, like IB, which have ack/nack it does</div>
<div>provide extra guarantee that it it reach remote NIC. But</div>
<div>even in this case it does not guarantee that it is in user remote buffer.</div>
<div> </div>
<div>For these type of guarantee you need application level ack.</div>
<div> </div>
<div>But there is one more guarantee that Send competion provides.</div>
<div>If data will not make it to remote side buffer the connection will be broken</div>
<div>before match recv on the other side will complete. Moreover, recv on another side</div>
<div>will not complete with success if the data had not arrived fully and without errors.</div>
<div>Thanks,</div>
<div>Arkady<br><br></div>
<div class="gmail_quote">On Tue, Mar 31, 2009 at 11:40 PM, 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">On Tue, Mar 31, 2009 at 6:01 PM, Jie Cai <<a href="mailto:Jie.Cai@cs.anu.edu.au">Jie.Cai@cs.anu.edu.au</a>> wrote:<br>
> Local side dat_ep_post_send message to remote side,<br>> with DAT_COMPLETION_DEFAULT_FLAG.<br>> Then the local side dat_evd_wait for the send completes.<br>><br>> Does the DTO completion event at local side of the<br>
> send indicates the data has been received at remote side<br>> as well?<br>><br>> I am bit confused about this.<br>><br>A DAT DTO send completion means that the DAT Provider and its<br>underlying Transport no longer require your buffers -- and that barring<br>
an error that tears down the connection, the data has been or will be<br>delivered to the remote peer.<br><br>This may mean as little as the transport layer has linearized your send<br>into its own buffer. Since most transport providers are not eager to<br>
volunteer vast amounts of transmit buffering it will frequently mean<br>s that the remote host has acked the data. That is the lowest cost<br>method for the sender to know that the source buffers are no longer<br>needed.<br>
<br>Even when the underlying transport guarantees that the data is in the<br>remote host's buffers, it does NOT guarantee that it is in the remote<br>peer's cache or that the remote peer has been scheduled or has<br>
in any way noticed that the memory has been updated.<br><br>The only guarantee that the remote peer *application* has gotten your<br>message is when it responds to it.<br>_______________________________________________<br>
general mailing list<br><a href="mailto:general@lists.openfabrics.org">general@lists.openfabrics.org</a><br><a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general" target="_blank">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general</a><br>
<br>To unsubscribe, please visit <a href="http://openib.org/mailman/listinfo/openib-general" target="_blank">http://openib.org/mailman/listinfo/openib-general</a><br></blockquote></div><br><br clear="all"><br>-- <br>Cheers,<br>
Arkady Kanevsky<br>