[ofa-general] Re: [GIT PULL] please pull infiniband.git

[Roland Dreier]

 > 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.