[openib-general][PATCH][kdapl]: evd upcall policy implementation

[James Lentini]

On Sun, 14 Aug 2005, Guy German wrote:

> James Lentini <mailto:jlentini at netapp.com> wrote:
> >> You changed the order in which the CQ upcall is enabled and the kDAPL
> >> upcall is made. It used to be:
> >> 
> >>  enable CQ upcall
> >>  call kDAPL upcall
> >> 
> >> you are proposing
> >> 
> >>  call kDAPL upcall
> >>  enable CQ upcall
> >> 
> >> I think your proposed order contains a race condition. Specifically
> >> if a work completion occurs after dapl_evd_upcall_trigger()
> >> returns but before the CQ upcall is re-enabled with
> >> ib_req_notify_cq(), no upcall will occur for the completion.
> >> 
> >> Do you agree?
> 
> Or, has turned my attention to the fact that also in the first case
> You have the alleged race: if a work completion occurs just
> before you enable the CQ upcall...

Correct, kDAPL will not receive a CQ upcall for such a completion, but 
it does notify the consumer that one or more completions have 
occurred. It is the consumer's responsibility to empty the EVD (CQ). 

In the scenario you describe, the consumer will not receive an upcall 
until the next work completion event which could take an arbitrary 
amount of time.

> Are you suggesting that enabling the CQ upcall will not trigger the
> CQ upcall, if completions happened before enabling? 
> I don't think this is the case, but I'm not 100% sure...

That is my assumption of how it works. This is how other 
verbs APIs have worked in the past.

> As I mentioned before, and regardless to this issue, I still believe 
> that the right order should be:
> >>  call kDAPL upcall
> >>  (conditionally) enable CQ upcall
> We can't have interrupts if the consumer disabled the upcall policy...

I agree that we should not request interrupts if the consumer disabled 
the upcall policy.