***SPAM*** Re: [ofa-general] uDAPL DTO completion question.

[arkady kanevsky]

Correct.
The only guarantee you have when you get Send completion is that
you can reuse the buffer and message has been sent.
It does not guarantee that message is in recv buffer.

For some transports, like IB, which have ack/nack it does
provide extra guarantee that it it reach remote NIC. But
even in this case it does not guarantee that it is in user remote buffer.

For these type of guarantee you need application level ack.

But there is one more guarantee that Send competion provides.
If data will not make it to remote side buffer the connection will be broken
before match recv on the other side will complete. Moreover, recv on another
side
will not complete with success if the data had not arrived fully and without
errors.
Thanks,
Arkady

On Tue, Mar 31, 2009 at 11:40 PM, Caitlin Bestler <caitlin.bestler at gmail.com
> wrote:

> On Tue, Mar 31, 2009 at 6:01 PM, Jie Cai <Jie.Cai at cs.anu.edu.au> wrote:
> > Local side dat_ep_post_send message to remote side,
> > with DAT_COMPLETION_DEFAULT_FLAG.
> > Then the local side dat_evd_wait for the send completes.
> >
> > Does the DTO completion event at local side of the
> > send indicates the data has been received at remote side
> > as well?
> >
> > I am bit confused about this.
> >
> A DAT DTO send completion means that the DAT Provider and its
> underlying Transport no longer require your buffers -- and that barring
> an error that tears down the connection, the data has been or will be
> delivered to the remote peer.
>
> This may mean as little as the transport layer has linearized your send
> into its own buffer. Since most transport providers are not eager to
> volunteer vast amounts of transmit buffering it will frequently mean
> s that the remote host has acked the data. That is the lowest cost
> method for the sender to know that the source buffers are no longer
> needed.
>
> Even when the underlying transport guarantees that the data is in the
> remote host's buffers, it does NOT guarantee that it is in the remote
> peer's cache or that the remote peer has been scheduled or has
> in any way noticed that the memory has been updated.
>
> The only guarantee that the remote peer *application* has gotten your
> message is when it responds to it.
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit
> http://openib.org/mailman/listinfo/openib-general
>



-- 
Cheers,
Arkady Kanevsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20090401/00fb158d/attachment.html>