> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> 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
_______________________________________________
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
