On Tue, 20 Jan 2004, David Brownell wrote:
I'd recommend you do that in your device driver, instead. Your completion callback can use urb->urb_list (so long as the URB hasn't been submitted!) and schedule the tasklet.
I did the tasklets driver thing first and in that mode I had perfect throughput w no dropped frames, till I hit this 'callback backlog', I added messages to prove what it was.
Sounds to me like you should be finding out what's keeping that tasklet from running before its deadline fires, and resolve that. Or maybe just fixing your IRQ threshold would resolve this.
I've been meaning to oprofile this, but haven't yet done so.
Me too! never enough time :)
Speeding up the IRQ handler path will of course be a fine thing, but from what you said so far it doesn't seem likely that'd be your bottleneck.
I did not eliminate interrupts, 'merely reduced their number... log2_irq_thresh = 6;
So one IRQ every 64 msec? That's likely causing lots of trouble all by itself.
This means that your queue depth should be something on the order of (64 msec + max IRQ latency + tasklet sched time).
My testing kept much shorter queue depths (10 msec), and never hiccupped.
- Dave
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
