Am Donnerstag, 15. Dezember 2005 16:58 schrieb Sam Bishop:
> 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.
>
> Of course, one answer would be, "Don't do that!" But with a sizable
> number of testers connected to the same host, I could see the result
> being the same, or similar, even during normal usage.
On second thought, the skeleton driver doesn't even limit the buffersize
to something sane. Triggering 128K allocations in unlimited numbers is
not nice at all.
Regards
Oliver
-------------------------------------------------------
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_idv37&alloc_id865&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
