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
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to