[Openib-windows] CM and timewait

[Sean Hefty]

>Should the CM enforce timewait at the QP level?  That is, should QP
>modifications fail while a QP is in timewait?
>
>The current gen2 Linux CM does not do this.  The existing IBAL CM does.
>The new CM in fab_cm_branch does for kernel QPs, but not for UM QPs,
>which is silly.  Kernel clients should be trusted, and user-mode should
>not, so either we should just drop it because timewait is generally so
>darn fast, or we need to enforce it for UM clients.
>
>The timewait would still be tracked in the CM at the connection endpoint
>level.  Obviously, removing tracking at the QP level is much easier than
>adding support to properly track it for UM QPs.
>
>Also, removing the interaction allows decoupling the CM from the QP a
>little more, and paves the way to exposing the CM's internal API to
>clients which would match the Linux usage model more closely.
>
>So what do y'all think?  Enforce or ditch timewait at the QP level?

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.  You would also need
to hold the QP in timewait after it was destroyed to prevent giving it back
to a different user.  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.
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 have a hard time imagining that you could go through the CM protocol
before being able to exit timewait however...

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.

- Sean