Sean> I don't think that sweeping the CQ in userspace eliminates
Sean> the race. The call to ibv_get_cq_event() can be just about
Sean> to return to the user when they call destroy in a separate
Sean> thread. Destroy has no way of blocking, so get could return
Sean> an invalid pointer.
Sorry, I was a little sloppy in my reasoning. The real reason I sweep
the CQ before returning from the destroy QP operation is for internal
libmthca implementation reasons. There's no requirement that this be
done in general, and in fact CQ entries corresponding to work requests
posted to a given QP may be polled after the QP is destroyed.
Section 11.2.4.4 of the IB spec (Destroy Queue Pair) says:
The CI does not guarantee that CQEs generated for a QP prior to its
destruction can be retrieved from the CQ after that QP has been
destroyed.
I take this to mean that it's fine if CQEs _are_ retrieved after a QP
is destroyed. Since a CQE does not have a pointer to the QP, but only
a QP number and a consumer-defined work request ID, I think this is
OK; there's no direct reference to a stale resource.
- R.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
