[Pvfs2-developers] Missing op_ids in pvfs2-ping?

[Scott Atchley]

On Dec 21, 2006, at 3:59 PM, Pete Wyckoff wrote:

> atchley at myri.com wrote on Thu, 21 Dec 2006 15:50 -0500:
>> I am trying to run pvfs2-ping. My bmi_mx connect messages are working
>> and the client and server can start handling BMI requests.
>>
>> Currently, I am seeing the following requests:
>>
>> Client posts a receive with op_id 5, bmi tag 1 and length 32808
>> Client posts an unexpected send with op_id 7, bmi tag 1 and length 24
>>
>> Server receives unexpected recv with bmi tag 1 and length 24
>> Server posts an expected send with op_id 79, bmi tag 1 and length 816
>>
>> I do not see any further posts of sends or receives. After ~20-30
>> seconds, I get the following messages:
>>
>> On the Client:
>> [E 15:40:10.538206] job_time_mgr_expire: job time out: cancelling bmi
>> operation, job_id: 4.
>> [E 15:40:10.538421] job_time_mgr_expire: job time out: cancelling bmi
>> operation, job_id: 6.
>>
>> On the Server:
>> [E 12/21 15:40] job_time_mgr_expire: job time out: cancelling bmi
>> operation, job_id: 78.
>>
>> I do not see where bmi_mx does gets these ops from BMI. What should I
>> check?
>
> Does the Client get the server's expected send?  Sounds like no.
> Why not?
>
> The op_ids are private to each side; no matching expected there.
>
> I don't exactly follow your question about "ops from BMI".
>
> 		-- Pete

I do not see the expected send on the client and I am looking into that.

I did not think the op_ids would match, but bmi_mx does not see the  
timed out ops in any post_send or post_recv functions. Are these  
operations passing through bmi_mx (possibly via other BMI_meth_*  
functions) or are these unrelated to bmi_mx?

Also, the client posts a receive with bmi tag 1 for a length of 32808  
but the server posts a send with bmi tag 1 and a length of 816. Is  
that normal?

Scott