[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