[Pvfs2-developers] BMI send implemtations

[Sam Lang]

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:
>>> MX provides 64 bits of match info for sends/recvs. I plan to
>>> partition the bits as follows:
>>>
>>> bits	comment
>>> 0-3	msg_type (conn_req, conn_ack, expected, unexpected, ...?)
>>> 4-7	reserved for credits (if used)
>>> 8-15 	reserved
>>> 15-31	peer id (16 bits => 65K peers)
>>> 32-63	BMI tag
>>>
>>> The conn_req and con_ack message types allow me to do a simple
>>> handshake to establish MX state (hostname, NIC index, endpoint  
>>> index)
>>> and agree on a version number. I'm reserving bits for credits should
>>> flow control be necessary and another 8 bits for future use if
>>> needed. I am assuming that 65K peers will be enough for awhile. If
>>> you think that PVFS will be deployed on systems with more than 65K
>>> 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
> _______________________________________________
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>