[openib-general][PATCH][kdapl]: FMR and EVD patch

[Guy German]

On Tue, 2005-08-30 at 10:40 -0400, James Lentini wrote:
> I'm not comfortable with a solution that relies on vendor specific 
> behavior for such a critical mechanism. 

I believe I suggested a solution for the general case as well:
1. request CQ notification
2. if cq !empty request CQ notification _again_ 

> What if dapl_evd_modify_upcall() worked as follows 
> 
> dapl_evd_modify_upcall
> 	lock evd with spin_lock_irqsave
> 	if CQ upcalls need to be enabled
> 		ib_req_notify_cq
> 	setup the evd upcall 
> 	unlock evd with spin_unlock_irqrestore
> 	if ib_peek_cq reports unreaped work completions
> 		call dapl_evd_dto_callback
> 
> I realize that the call to dapl_evd_dto_callback() will potentially be 
> racing with a CQ upcall, but I believe that the logic in 
> dapl_evd_dto_callback() handles that correctly.

I don't think it's a good idea to call the consumer _again_ in the
consumer's own context ... 
Usually the upcall is interrupt/tasklet context that wakes up the thread
- now, you suggest that the thread will "wakeup" itself (when it is,
actually, already running and about to go to sleep) 

Guy.