On Tue, 9 Sep 2003, Baldrick wrote:
Hi Alan, since you didn't squelch those ideas how about this even wilder one:
it seems to me that for IN transfers (I am thinking bulk) it is possible to allocate
no TDs whatsoever!
How about a different radical approach. Remembering that there's already a queue of URBs in the HCD glue, it's clear that they don't all need to have TDs immediately allocated ... when an endpoint queue is "empty enough", the lower level HCD code could check for urbs that are queued to that endpoint but which don't yet have TDs, then allocate (and queue) TDs for those URBs.
That notion could be combined with the notion of TD queues that are throttled in the same way many network drivers throttle. For example, maybe a bulk endpoint would have no more than 40 TDs at a given moment ... that's enough to keep the controller busy for about two frames. Whenever a set of TDs completes from the front of the td list, they could be recycled to advance transfers starting from end of that td list. (Implies recycling TDs as the HC returns them, instead of when the HCD returns urbs.)
One of the key differences between UHCI and EHCI (or OHCI) is that only UHCI uses packet-at-a-time TDs. Which means that a given request is going to need many more TDs. It seems to me that strategies to limit TD usage (like those two) would be particularly beneficial with UHCI.
Allocation and freeing of TD's isn't as much of a problem as you seem to think. Although shrinking them certainly won't hurt, they are taken from a pre-allocated pool of DMA-coherent memory. Allocation and freeing are thus extremely quick.
They're not necessarily pre-allocated; the pool size will grow in some cases (doesn't currently shrink). But with UHCI the pool can grow to be quite huge ... and most of those TDS are sitting idle most of the time. While desktop machines may not have particular problems running short of memory, that's not always true. The volume of TDs can be a problem even if allocating the next one isn't.
- Dave
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
