[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
> 
>  > > I'm still thinking about synchronizing with the completion EQ's irq.
>  > 
>  > Let's discuss this? Can you formulate what's bothering you?
> 
> I don't like the fact that it's very hard to even write down exactly
> what we're guaranteeing.  So it's not clear to me that other low-level
> drivers statisfy the constraint (since I'm not sure what the
> constraint is).

Here is the rule.
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?

> Also it just helps with one particular case of a class of bugs --
> there are many other ways that polling a CQ could fail to synchronize
> with destroying a QP.  I'd rather try to avoid the whole class of bugs.

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)

-- 
MST