[ofa-general] Re: IPOIB CM (NOSRQ)[PATCH V2] patch for review

[Pradeep Satyanarayana]

Thanks for the clarifications Roland. There is something that I am still 
missing- I presume the Local
CA Ack Delay is common across all QPs in the HCA and the Local Ack Timeout 
is specific
to each QP. Is that correct?
 
I tried to change the ib_qp_attr .timeout value (this is the Local Ack 
Timeout -right?) to 0xf as the QP 
transitions from RTR to RTS (page 569 IB Spec) . A subsequent 
ib_query_qp() tells me that timeout = 0.
This happens on both ehca and mthca.

There may be a CM bug, but I am guessing somthing else is incorrect too. I 
have not yet narrowed 
that down.

Pradeep
pradeep at us.ibm.com


Roland Dreier <rdreier at cisco.com> wrote on 04/24/2007 11:33:25 AM:

>  > As previously stated, IBM HCA will address these issues. However,
>  > my understanding is that mthca/Topspin adapters also have a problem
>  > (too high a value for the Local CA Delay Ack). Both HCAs need to be
>  > fixed for good interoperability.
> 
> I think you're misunderstanding what local CA ack delay means.  This
> is a property of an HCA that is not (necessarily) subject to tuning --
> it is just a property of the HCA, namely the maximum amount of time it
> may take to generate an ACK.
> 
> So if a certain HCA reports a value of 15, then that means that any
> remote HCA talking to it must be prepared for a delay of 4.096 * 2^15
> usecs before receiving an ACK.
> 
> If the ACK delays on both sides are not being taken into account
> properly when establishing a connection, then I guess that is a bug in
> our CM.
> 
>  - R.