On Tue, Jul 27, 2010 at 8:20 PM, Jason Gunthorpe <[email protected]> wrote: > On Tue, Jul 27, 2010 at 08:03:25PM +0200, Bart Van Assche wrote: > >> As far as I know it is not possible for a HCA to tell whether or not a >> CPU has finished executing the interrupt it triggered. So it is not >> possible for the HCA to implement the above requirement by delaying >> the generation of a new interrupt -- implementing the above > > Linux does not allow interrupts to re-enter.. Read through > kernel/irq/chip.c handle_edge_irq to get a sense of how that is done > for MSI. Looked to me like all the CQ call backs flowed from the > interrupt handler in mlx4?
The above implies that one must be careful when applying a common Linux practice, that is to defer interrupt handling from IRQ context to tasklet context. Since tasklets are executed with interrupts enabled, invoking ib_req_notify_cq(cq, IB_CQ_NEXT_COMP) from tasklet context may cause concurrent execution of an IB IRQ with an IB tasklet. So if ib_poll_cq() is invoked from tasklet context, the entire polling loop has to be protected against concurrent execution. As far as I know such protection against concurrent execution is not necessary inside tasklets that handle other types of hardware. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
