On Thu, Dec 15, 2005 at 08:58:39AM -0700, Sam Bishop wrote: > Hello, > > I maintain a 2.4 USB driver based off an old version of usb-skeleton.c. > (It's for an in-house tester used where I work, and the choice of kernel > version is out of my hands.) I've just taken a look at the latest (2.6) > version of usb-skeleton.c, and I'm wondering if someone would be > generous enough to explain to me how a part of it works. > > It's the writes I'm wondering about. It appears that the code allocates > a new URB and buffer for each write. Once the write is completed, the > associated URB and buffer are freed. But one of the ways I benchmark > our download speeds is by filling a 4K buffer with valid packets and > looping over a single write(2) call. With the CPU being so much faster > than USB and an URB/buffer pair being allocated for each write, it would > seem like it wouldn't be long before an -ENOMEM was returned.
You are right, as Oliver pointed out. If you look at drivers that copy this scheme (like visor.c), they put an upper limit on the number of urbs that can be in flight at any one time. I'd be glad to accept a change to the usb-skeleton.c driver that adds this logic if you want to make up a patch. thanks, greg k-h ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
