On Sun, 2010-08-08 at 20:19 +0200, Bart Van Assche wrote: > On Sat, Aug 7, 2010 at 6:32 PM, Roland Dreier <rdre...@cisco.com> wrote: > > Not sure that I follow the problem you're worried about. A given > > tasklet can only be running on one CPU at any one time -- if an > > interrupt occurs and reschedules the tasklet then it just runs again > > when it exits. > > > > Also I'm not sure I understand why this is special for IB hardware -- > > standard practice is for interrupt handlers to clear the interrupt > > source and reenable interrupts, so I don't see why the same thing you > > describe can't happen with any interrupt-generating device that defers > > work to a tasklet. > > One of the applications I have been looking at is adding blk-iopoll > support in ib_srp and to make it possible to enable and disable > blk-iopoll at runtime via sysfs. A naive implementation could look > e.g. as follows:
I'm not sure it makes sense to enable/disable this at runtime -- we don't do it for NAPI, why do it for block devices? I'm not even sure I'd want to see a config option for it in kbuild -- that was done during the transition to NAPI and it lingered forever for some drivers. I'd rather we got it correct, and not give people yet another knob to figure out. I can certainly see a use case for testing the patch's performance, though. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
