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

[Michael S. Tsirkin]

> Quoting Roland Dreier <rdreier at cisco.com>:
> 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