> Quoting Roland Dreier <[EMAIL PROTECTED]>: > Subject: Re: [ofa-general] Re: [GIT PULL] please pull infiniband.git > > > 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.
Exactly, that's why this sync belongs in QP reset. I get your point now. -- MST _______________________________________________ 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
