On Aug 23, 2006, at 11:17 AM, Sam Lang wrote:
On Aug 22, 2006, at 6:44 PM, Scott Atchley wrote:
On Aug 22, 2006, at 5:14 PM, Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Tue, 22 Aug 2006 16:18 -0400:
<snip>
peers, I can pull from the reserved bits to increase this id.
Lastly,
I will pass the BMI tag, which is 32 bits.
I am assuming that a call to BMI_post_send() will have a matching
call to BMI_post_recv() on the remote peer and that both will share
the same BMI tag. If not, then please let me know.
Sounds like you have a good handle on things. Tags do have to
match, and you do in-order matching on identical peer+tag. So your
network better not re-order or you need to add a sequence number.
-- Pete
MX does in-order delivery but I thought the tag was a sequence
number of sorts.
I thought it only did in-order matching instead of in-order
delivery, which is why the tag works for us in this case.
-sam
Scott
I misspoke. MX does do in-order matching, not delivery. If A posts
Recv1 then Recv2 and B posts Send1 and Send2 and both sends can match
both receives, A's MX will ensure that Recv1 matches Send1 and Recv2
matches Send2.
It may be, however, that Recv2 completes before Recv1. Would that be
an issue? If so, I can keep a completed request queue and return them
in BMI_testcontext() in order.
Scott
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
