On Fri, 9 Apr 2004, David Brownell wrote:
Doing less at IRQ time is certainly good, but I think there are ways to shorten the code paths without doing that. Device drivers should use tasklets if they have lots of work to do; HCDs normally just have a handful of TDs to process, and that should be quite reasonably done in an IRQ handler.
What about completion of a scatter-gather transfer for 64 KB or more, not at all unusual for usb-storage? Although the transfer is generally broken up into 4-KB URBs (corresponding to memory pages), the s-g library uses the URB_NO_INTERRUPT flag to suppress completion interrupts until all the URBs have been transferred. That interrupt will have to process 1024 or more TDs and call 16 completion handlers.
Is that more than a handful?
Calling usb/core/message::sg_complete() 16 times is not much work at all in the typical no-errors case.
TD scanning should always be fast-pathed, but since UHCI uses so many of them it might be appropriate for uhci-hcd to ignore the NO_INTERRUPT hint.
I think the IRQ rate is the key issue there. At USB 1.1 speeds, an IRQ for each urb of 4 KB means one IRQ every 3-4 msec; that's not a painful rate. OHCI uses URB_NO_INTERRUPT to reduce that rate to one every 6 msec, so big transfers might take up to half the IRQs they would otherwise.
But at high speed, that flag keeps the IRQ rate from being unreasonable: one per URB would be at least 8 IRQs/msec, which is not a reasonable rate.
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
