On Wed, 21 Jul 2004, Oliver Neukum wrote: > Am Mittwoch, 21. Juli 2004 18:17 schrieb Matthew Dharm: > > The only idea I had was to force URBs to be allocated in a manner such that > > they are associated with a device (and thus, by implication, with a > > particular controller and it's DMA pool). �Then, we can make any > > allocations that the core or HCD might need at that time. > > > > This would complicate URB management for higher-level drivers. �But really, > > what driver right now has a pool of URBs which are shared among multiple > > devices? �I just don't see this as a large hurdle.... > > > > Comments? > > You are right. We've discussed it. You'd have to set the maximum buffer > an URB can transmit at allocation time.
Yes, because the HCD may need to allocate space from its private pools based on the total length of the URB's transfer buffer. It's unclear to me to what extent all these things really need to be allocated beforehand, however. Certainly for things like usb-storage it makes sense to do this with buffers involved in actual data transfers, to minimize latency if nothing else. But for subsidiary usages, like the URBs and buffers used in doing a reset? These are pretty rare and not especially time-critical, although they do need to use GFP_NOIO. > It would have more benefits, even > in unlikely places like usb_kill_urb(). I'm puzzled how pre-allocation would help usb_kill_urb(). > Yet it is a major rewrite and we decided that it's 2.7 matter. It's one of the items on the slate -- but note that the Gadget API does this already. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
