Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > Subject: Re: [PATCH ] RFC IB/cm do not track remote QPN in timewait state > > Sean Hefty wrote: > > How would the driver determine how long the QP should remain in timewait > > The spec isn't totally clear to me on this, but here's what I can gather: > > timewait = packet lifetime x 2 + remote ack delay > local_ack_timeout (in CM REQ) = packet lifetime x 2 + local ack delay > > Verbs gets local_ack_timeout through qp_attr.timeout when modifying the QP to > RTS.
Isn't that RTR? > But from 12.7.34, I believe that the local_ack_timeout used by verbs is > for the remote QP, meaning that: > > local_ack_timeout (verbs) = packet lifetime x 2 + remote ack delay > > which is also the timewait value. Do you concur? If so, then verbs already > has > the timewait value. I agree. 11.2.4.3 which defines Local Ack Timeout in QP even has a link to this REQ field. So it seems we won't need any API changes. This begins to look good. I waner what Roland and other low level driver maintainers think. -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
