On Sun, 1 Jul 2007, Oliver Neukum wrote: > Am Sonntag, 1. Juli 2007 schrieb Alan Stern: > > It's not entirely clear what you're trying to accomplish by doing this. > > > > First, notice that pre-allocation is useless with one-shot URBs, since > > the resources would be allocated anyway as soon as the URB is > > Yes, obviously. > > > submitted. You gain an advantage only by avoiding having the resources > > deallocated when the URB completes, so that they can be reused when the > > URB is resubmitted. (Or possibly when a different URB is submitted for > > the same endpoint.) How will your changes affect deallocation? > > It happens when the URB is destroyed.
I'm not convinced that it's a good idea to couple allocations and deallocation to URBs like this. They could be handled separately from URBs. > > Notice also that the usb-storage doesn't reuse URBs for its large data > > transfers (ub might work differently; I don't know). Those are all > > done using one-shot URBs allocated by the scatter-gather library. Do > > you intend to change how that works? > > That is a long term goal and would require some invasive changes in > the storage driver. It shouldn't require changes to usb-storage, only changes to the s-g library. > > Another thing worth noticing is that with reusable URBs, at allocation > > time you might not know the transfer lengths you will need. Drivers > > would have to guess at the maximum requirement and then live with that > > guess. > > I doubt this is a common problem. Only rarely will a driver transfer > more than PAGE_SIZE. If you look at usbmon logs of real usb-storage data transfers you'll see that multi-page sg elements occur quite frequently. (Of course, that doesn't prevent us from transferring only one page per URB.) > > Finally, don't forget the advantages of avoiding preallocation and > > keeping resources in a pool, available for multiple uses. > > What are these, beyond memory usage? There aren't any others, clearly. But memory usage is enough. > My goals are: > > - speed up things for drivers that maintain pools of URBs: > some serial drivers, cdc-acm, video drivers ... Your work would have the opposite effect! By tying URBs to specific endpoints, you would force these drivers to stop using URB pools. (Although that might not be a bad thing in the long run...) Or maybe the drivers would dedicate a pool for each individual device, instead of allowing all devices to use URBs from a common pool. So okay, for streaming or almost-streaming transfers you would speed things up by avoiding the constant allocation and deallocation. I still think it might be better to do this at the level of endpoints rather than individual URBs. Keep in mind that this is how our current USB stack is oriented: towards endpoint queues, not single URBs. Unlike the previous stack. > - reduce CPU usage in interrupt handlers and in general > - remove some nasty ENOMEM error cases > - guarantee the storage driver a fallback path without memory allocation Worthy goals. But is this the best way to accomplish them? Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
