[openib-general] [PATCH] Re: uDAPL again

Hal Rosenstock halr at voltaire.com
Thu Nov 3 09:57:46 PST 2005


Hi Arlin,

On Thu, 2005-11-03 at 12:51, Arlin Davis wrote:
> Arlin Davis wrote:
> 
> > Aniruddha Bohra wrote:
> >
> >> I am not sure, but arent uCM and uAT simply for connection 
> >> establishment?
> >>
> > Yes, but they also set up many of the transfer attributes of the 
> > connected QP. The uCM/uAT version uses path_records from the SA query 
> > but the socket_CM version just builds them by hand similiar to the way 
> > ibv_rc_pingpong does. You would have to look at the 
> > pathrecord->pktlifetime to see the actual timeout value being used.
> >
> Ok, I added some debug and it looks like the path record returned from 
> uAT looks suspect. Here are the results from tuAT and opensm running on 
> my cluster. Path record pktlife is 0 (uCM adds 1) so the ACK timeout 
> value for this connection will be very short.
> 
>  path_comp_handler: ctxt 0x525fa0, req_id 90 rec_num 1
>  path_comp_handler: SRC GID subnet fe80000000000000 id 0002c9020000409d
>  path_comp_handler: DST GID subnet fe80000000000000 id 0002c90200004071
>  path_comp_handler: slid 5 dlid 2 mtu 120203(2) pktlife 
> 0(0)                   <<<  ???
>  path_comp_handler: hops 0 npaths 0 pkey ffff tclass 0 rate 
> 0(0)              <<<  ???
> 
> Hal, can you take a look at uAT and see if the copy to user space is 
> working correctly.

Just want to clarify what I should be looking for:

So you suspect pktlife and rate being bad (and the rest of the SA PR
look OK) ?

Is OpenSM being used in Aniruddha's subnet ?

-- Hal




More information about the general mailing list