[Pvfs2-developers] BMI send implemtations

[Scott Atchley]

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:
>>
>>> atchley at myri.com 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