[openib-general] [PATCH ] RFC IB/cm do not track remote QPN in timewait state

[Michael S. Tsirkin]

Quoting r. Sean Hefty <mshefty at ichips.intel.com>:
> Subject: Re: [openib-general] [PATCH ] RFC IB/cm do not track remote QPN in timewait state
> 
> Michael S. Tsirkin wrote:
> > IB spec, section 12.4, says:
> > 
> > 	CMs shall maintain enough connection state information to detect an attempt
> > 	to initiate a connection on a remote QP/EEC that has not been released
> > 	from a connection with a local QP/EEC, or that is in the TimeWait
> > 	state. Such an event could occur if the remote CM had dropped the connection
> > 	and sent DREQ, but the DREQ was not received by the local CM.
> > 	If the local CM receives a REQ that includes a QPN (or EECN if
> > 	REQ:RDC Exists is not set), that it believes to be connected to a local
> > 	QP/EEC, the local CM shall act as defined in section 12.9.8.3.
> > 
> > Note here, that while CM must maintain QPs in TimeWait state (to enable
> > detection of TimeWait packets, as explained in 9.7.1 PACKET SEQUENCE NUMBERS),
> > such QPs are not connected (they are normally in reset state).
> > Thus even if a local QP was connected to a specific remote QPN, once the
> > connection enters the timewait state CM must not reject the connection request
> > even if it includes the specific remote QPN.
> 
> My interpretation of 12.4 is:
> 
> The CM should track remote QPs that are either:
> 
> 1. Part of an active connection, or
> 2. A connection that has been placed into timewait.
> 
> The CM should detect attempts to connect such remote QPs, and reject them.  The 
> entire paragraph is referring to stale connection handling, and I believe the 
> reference to timewait is included as part of that general discussion.

So, you must somehow detect that the remote QP is in timewait state.
I don't see any way to do this, and this is not what the CM
currently does.

Our CM tracks local QPs in timewait state, which is obviously not
what the spec intends since remote QP could be reused even though
local QP is in timewait.

-- 
MST