On Tue, 2005-08-30 at 12:28 -0400, James Lentini wrote: > > 1. request CQ notification > > 2. if cq !empty request CQ notification _again_ > > Can you explain step #2 in more detail? What does "CQ notification > _again_" entail?
I was confusing 2 different things - sorry. The way I see it - there are 2 issues : the first issue is the verbs (which at this point in time is a bit more relevant). AFAICT, the way the verbs completion works, there should be no race: - upcall received - wakes up thread - thread requests completion notification - thread poll the rest of the cq and exit The difference between the verbs model and the kDAPL event model is that the upcall does not drain a wc from the cq - just notifies you that a completion arrived. You don't need to worry here about synchronizing a thread and an interrupt dequeue-ing from the same queue. The second issue is the race in kDAPL. Here the dapl already reaped an event for the consumer and it is delivered in the upcall, so it is more problematic to allow the thread and the upcall work simultaneously. If you don't want to rely on Mellanox's proprietary behavior you can do as you suggested (call dapl_evd_dto_callback again), but you also need to skip context (preferably to a tasklet). Guy _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
