[openib-general] [PATCH ] RFC IB/cm do not track remote QPN in timewait state
Michael S. Tsirkin
mst at mellanox.co.il
Tue Aug 29 12:08:41 PDT 2006
Quoting r. Sean Hefty <mshefty at ichips.intel.com>:
> 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
More information about the general
mailing list