>> Just to emphasize what Sean has pointed out, you are asking how can a CM >> consumer know that a **local** QPN is not in the timewait state >> according to the **remote** CM. Since the issue is with the remote CM, >> it seems to me that pushing down timewait into verbs is not the correct >> direction to look at.
We should still ensure that we don't give a user a local QPN that we know is in timewait. For example, a user 1 connects over a QP, transfers some data, then destroys the QP. User 2 allocates a new QP. Can user 2 get the same QP as the user 1? If so, user 2 is likely to see a stale connection. An option at this point is for user 2 to destroy the QP and allocate a new one. If they do this, will they get the same QP again? Now imagine if user 1 had created 1000 connections. I believe that we should make things as easy on user 2 as possible, including reducing the chance of giving them a QP that the remote side is likely to have in timewait. - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
