[ofa-general] uDAPL DTO completion question.

Jie Cai Jie.Cai at cs.anu.edu.au
Tue Mar 31 23:41:03 PDT 2009


Understood now. A further question is here again.

To implement software level acknowledgment to inform initiator that data
has been available for remoter, is that possible to use a busy loop at 
remote
side to detect the last element of transferring has appear in the memory.

Or remoter has to wait for the event of recv matching initiator's send, then
send a message back to initiator as a acknowledgment?

I have tried with busy loop implementation, but failed. Memory of last 
element
does not changed at all. I guess DAPL may not allow user to modify the 
recv buffer
when there is a incoming message into it.

Please kindly clarify this.

arkady kanevsky wrote:
> 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 <mailto:caitlin.bestler at gmail.com>> wrote:
>
>     On Tue, Mar 31, 2009 at 6:01 PM, Jie Cai <Jie.Cai at cs.anu.edu.au
>     <mailto: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 <mailto: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



More information about the general mailing list