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