What really should happen is that the field Local Ack Timeout in REQ
should be (2 * PacketLifeTime + Local CA’s ACK delay) (see 12.7.34)
and then the responder should use this for it's QP.
Just to clarify, the value is _based_ on (2 * PacketLifeTime + local CA ack
delay). For example, if
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
Hello Roland,
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.
So for each IPoIB connection, the ACK delays could be different from
remote. Then how TCP retransmission timeout have a
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
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.
I looked, and the cm does not take into account the ca ack delay. This can be
worked around by bumping up the qp timeout value between calling
Quoting Sean Hefty [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: IPOIB CM (NOSRQ)[PATCH V2] patch for review
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.
I looked, and the cm does
