Oliver Neukum wrote:
Am Donnerstag, 16. Januar 2003 01:52 schrieb David Brownell:

- 1..N TDs ... dependant on the specific buffer passed later,
  except (usually) for ISO (where i == n)
What prevents you from allocating a reasonable number in the general case
and as many as you may need in the iso case?
What, and have _two_ code paths to debug/stabilize in the
hairy hardware-specific logic ... one where you guessed
right, and one where you guessed wrong?

Very good point.
So I'll get a 2.0 device and after that I'll code something and
do benchmarks. After 2.7.0 we can discuss this again.
OK ?
Sure. I could see for example usb_buffer_map() as a way to
ensure the buffer's TDs are pre-allocated. (Except for ISO,
which has as strange buffering model.)

Were you wanting to do anything about that urb->hcpriv[]
pre-allocation? I see no reason not to do that part, and
it'd mean that the submit path won't usually need to hit the
slab pool again until after the submit completes.

- Dave





-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to