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

[James Lentini]

On Tue, 30 Aug 2005, Guy German wrote:

> 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:

Sorry I missed this in you mail. 

> 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?

> > 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) 

I agree that it is complicated. Using iSER as an example, the thread 
in iser_event_handler_thread() would:

 - consume the events in iser_consume_events()
 - set the has_first_event flag to false
 - call dat_evd_modify_upcall()...
 - ...which would potentially call iser_evd_upcall() and set the 
   has_first_event flag to true
 - iser_evd_upcall() returns
 - dat_evd_modify_upcall() returns
 - iser_consume_events() returns
 - the event handler thread's call to wait_event_interruptible() 
   would not put the thread to sleep because the has_first_event 
   flag would be true