[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