[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: [PATCH ] RFC IB/cm do not track remote QPN in timewait state
> 
> Michael S. Tsirkin wrote:
> > 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.
> 
> The CM tracks the remote QP, not the local.

I might not have been clear.
For connection in timewait state, spec explicitly says local QP
must be in reset, error or init.
Only after it goes out of timewait can you destroy the QP.
That's the tracking I think spec means CM needs to do.

> The spec (12.4) seems to state
> that this is required by the CM.

Tracking, yes. But the not rejecting connections.

>  Do you disagree with my interpretation of
> 12.4, or why do you think that this is obviously not what the spec intends?

It seems I disagree with your interpretation of the spec.
I think what the spec intends is CM must track 2 kinds of QPs:
1. remote QPN used in Connected QPs - to detect stale connections
2. Local QPs in timewait state - QP must not be destroyed immediately, but must
   stay in reset, error or init so that harware discards timewait packets

These 2 are mutually exclusive.
In case 1 a new REQ with same remote QPN means connection got stale.
In case 2 we exchanged DREQ/DREP so there's no issue.

-- 
MST