On Mon, 2 Jul 2007, Oliver Neukum wrote: > Am Montag, 2. Juli 2007 schrieb Alan Stern: > > On Sun, 1 Jul 2007, Oliver Neukum wrote: > > > > 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. > > Yes, but what for? > The earliest possible time is when the URB is allocated, the latest time > is at usb_submit_urb(). Anything in between requires a further function > call.
Not so. The resources can be _allocated_ arbitrarily early. The earliest possible time they could be _used_ is when an URB is submitted (not when it is allocated!). Furthermore, if you do things this way then you could share an endpoint's resources among a bunch of URBs. For example, suppose you stream data to an endpoint, using 8 URBs. Doesn't it make sense to allocate sufficient endpoint resources for all 8 in one function call, rather than allocating the resources for each URB along with that URB? > > 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.) > > OK, but the storage driver allocates the URBs on the fly. If we change > that to preallocation we need to have enough URBs for the worst case. (The s-g library allocates those URBs, not usb-storage.) We _don't_ have to preallocate enough URBs for the worst case. At most we should preallocate enough to keep the pipeline filled. In case of bad memory pressure, we can live with preallocating only one URB. It'll be slow, but it's better than failing the I/O. > cdc-acm already does use one pool per device. Which drivers work otherwise? > They will scale badly for multiple devices. Common pools are a bad idea. I thought the serial drivers did, but my impression was wrong. > > 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. > > Please elaborate. I thought that by linking URBs to endpoints, I'd > orient the stack towards endpoints, not individual URBs. Only partially. It makes sense to say that you want to preallocate enough storage to transfer 32 KB to an endpoint. It doesn't make as much sense to preallocate 4 KB worth of storage to each of 8 URBs. The fact is that bulk endpoints consume an almost uniform stream of data, with only short packets to mark any sort of boundary. The division of that stream into URBs is rather artificial; for bulk streaming it mainly reflects the inability of the HCDs to handle scatterlists. Besides, there's also the practical aspect. If you force URBs to be linked to endpoints, you will have to audit many drivers. I don't know how many of them will need changes. But adding new function calls for preallocation and release will affect only a few HCDs plus whatever drivers want to use the new calls. 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
