[Openib-windows] CM and timewait

[Fab Tillier]

> From: Sean Hefty [mailto:sean.hefty at intel.com]
> Sent: Thursday, June 02, 2005 4:17 PM
> 
> Trying to enforce timewait at the QP level implies to me that you need a
> mechanism to notify the user when the QP can be reused.

That is currently done by failing a QP modify request with a status of
IB_QP_IN_TIMEWAIT.

> You would also need to hold the QP in timewait after it was destroyed to
> prevent giving it back to a different user.

The HCA driver increments a counter in the upper bits of the QPN to achieve this
result.  I suppose there could be a risk or reusing a QPN if the QPs get
created/destroyed fast enough, but I think that risk is minimal.

> Without time wait, it seems that in the worst case you
> have a UM app that receives data intended for the previous owner of the QP.

Actually, this worst case only comes into play if users manually setup their QPs
without using the CM protocol.  The CM protocol will prevent these connection
attempts if a CEP is in timewait.

> On the other hand, if an app wants to reuse a QP immediately is there any
> reason to prevent them from doing so?  With proper PSN values, old packets
> may not matter.

I'm leaning towards letting apps that want to hose themselves do so.  Plus,
stale packets only come into play if you re-establish a connection with exactly
the same destination QP.  Seems rather unlikely.

> 
> I have a hard time imagining that you could go through the CM protocol
> before being able to exit timewait however...

I think I agree.  I'm leaning towards eliminating the QP-level tracking.

> 
> There - did I sufficiently not answer the question?  If it doesn't add
> substantial implementation complexity, enforcement at the QP level seems the
> most reliable.

The complexity is a PITA for doing this for UM QPs.  KM QPs are easy to deal
with.

Thanks for the feedback,

- Fab