On Apr 27, 2009, at 9:02 AM, Vinod tipparaju wrote:
> Don't forget matching. The model depends on a relation between send
> and receive. This is the fundamental reason for potential difference
> in overlap. If you talk implementation, which we technically
> shouldn't for this argument, eventually the fact that a matching
> receiver is required for a send does impact over multiple sends.
>
> the one-sided model
>
> a->b
>
> is independent of b.
>
> the two sided model
>
> a<->b
>
> because of its dependance implies validity -- you can hide the cost
> of validity but can't eliminate it.
>
> Vinod.
Ok, I am stepping in over my head here and Patrick may slap me for
doing so. :-)
Doesn't one-sided also require some form of matching in the
implementation of A->B to determine where the bytes go in B? Call it a
rkey or whatever you want, there is some form of address hint that
requires translation to place the data in the right buffer. It can be
done on NIC or elsewhere, but it is not free.
My view of one-sided and two-sided is simply one from a library user
(to implement an application). Originally, I drank from the cup of the
One-Sided and helped implement a wide-area, capability-based, file
transfer service. Our users, however, always wanted to know when an
operation completed, which required an extra notification message. It
is that notification that always leads me back to two-sided.
Surely I am missing something obvious (and please let me know), but I
always thought that the biggest benefit to one sided is the case where
A->B multiple times and B does not have to reregister/repost the
buffer. But if A has to notify B that the data is there (or B has to
poll on a byte or doorbell), how is that different than checking the
completion of a receive?
Overlap can be accomplished in either method (don't use blocking send/
recv).
Scott
