On Mon, 2 Jul 2007, Oliver Neukum wrote: > > 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? > > Up to a point. Particularly not when it means taking more interrupts. > RAM is growing faster than cpu speed.
The number of interrupts is orthogonal to the question of whether HCD resources are bound to endpoints or to URBs. And don't forget that while RAM may indeed by growing faster than CPU speed, there are plenty of small or embedded systems without much of either. They can afford to spend extra CPU time more easily than extra RAM. Deciding on the tradeoff between memory use and number of interrupts is difficult. Are there any statistics we can use at runtime to make such decisions? > > 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. > > Iff we are willing to have two code paths. It will depend on the implementation. > Furthermore, I am afraid > of giving all remaining memory to URBs and not leaving enough for > allocation private to the HCDs. That's an argument for preallocating fewer URBs, not more. > > > 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. > > But the amount of resources needed depends on the granularity. Yes. But once you have decided on the amount of resources, the question remains: Should those resources all be associated with the endpoint or should they be split up among a bunch of URBs? Here's something else to think about. The resources needed for a transfer are not small (at least, not with UHCI). But usb-storage does transfers in only one direction at a time. If you allocate a large amount of memory for both the IN and the OUT bulk endpoints, you will always waste at least half of it. So maybe the allocation shouldn't even be per-endpoint. > Yes, so an URB describes a part of a stream contiguous to DMA. > As this granularity determines the number of tds, qtds ... needed, this > seems sensible to me. So the minimum granularity is determined by the DMA description (the scatterlist). A reasonable maximum granularity would be one page per URB. The difference between those two figures won't be too big. In any case, I thought you intended to preallocate all this stuff long before the actual transfer occurs (like during a probe routine). So at allocation time you wouldn't know the granularity anyway. For example, let's say you decide to preallocate resources for a mass storage device during usb-storage's probe routine. You don't know how big the transfers will end up being, so you preallocate enough for 120 KB. But the user increases max_sectors and you are faced with a 200-KB transfer. What will you do? > > 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. > > Yes, but after that audit there'll be a unified API again. But there's already a unified API. Why go out of your way to un-unify it? 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
