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
<[email protected] <mailto:[email protected]>> wrote:
On Tue, Mar 31, 2009 at 6:01 PM, Jie Cai <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general
--
Cheers,
Arkady Kanevsky
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
