[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:
> > Comments appreciated.
> 
> I will look at the spec in more details, but I thought that timewait was 
> included as part of the life of a connection.  I.e. the connection wasn't 
> released until it returned to idle.

Here's a quote:
12.9.4 STATE DIAGRAM NOTES


	When the Consumer wishes to destroy a QP or EEC that is in the Established
	CM state, it is good practice for the Consumer to first release the
	connection before destroying the QP or EEC. Doing so allows any state
	maintained by CM related to the QP or EEC in question to be cleaned up.
	A connection is released by moving from the Established state to the
	TimeWait state using one of the state transition sequences described in
	the sections that follow.

So yes, connection in TimeWait is released.

> Also, isn't the purpose behind timewait to 
> prevent re-connecting a QP while there are outstanding packets on the fabric 
> that could be associated with the QP?

Yes, and for that we need *not* track the remote QPN in timewait -
instead, we must keep the local QP around in reset, error or init state:

	When the CM state is IDLE, LISTEN, or TimeWait, the QP or EE Context
	is allowed to be in any of the Error, Reset, or Initialized states.

That's exactly my point:
- timewait is to flush out outstanding packets (even after DREQ/DREP completed)
- stale connection detection is for when one of the sides loses connection
  information - needed only if DREQ was lost

These two are not related.

-- 
MST