> It should be guaranteed that no event handlers - completion events or async > events - > for this QP - are in progress after QP has been destroyed or moved to reset > state. > > Does this make sense?
No, because completion handlers are not attached to QPs. So it is entirely possible for CQs to generate new events because of other QPs and have completion handlers running at any time. You end up trying to say something about visibility of CQEs for the QP being destroyed in completion handler context, and I think it turns into a confusing mess. > Agreed. > I think the rest of ULPs are taken care of if we replace > qp pointer in ib_wc with qpn + qp_context pair. > Have you seen this patch? > > This way a ULP can stick a pointer to its own structure > and in polling thread, do: > > foo = wc.qp_context; > if (unlikely(foo->dead)) > return; > > and to destroy the QP: > foo->dead = 1; > ib_destroy_qp(qp) > flush(polling thread) > free(foo) It makes some sense. But we hit the problem that there is no way to flush completion handlers right now. Which is why I can't reject the synchronize_irq for completion irq change -- exposing some sort of "sync completion handlers" API seems error-prone too. - R. _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
