Am Montag, 2. Juli 2007 schrieb Alan Stern:
> 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!).
OK, so the earliest time they can be cleared for use by an URB
is when the URB is allocated. The allocation can be at any time
before that.
> 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.
> > > 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.
Iff we are willing to have two code paths. Furthermore, I am afraid
of giving all remaining memory to URBs and not leaving enough for
allocation private to the HCDs.
> > > 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.
But the amount of resources needed depends on the granularity.
> 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.
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.
Of course, it's not a necessity to use URBs, but firstly an asynchronous
API will need some kind of handle and secondly I had not envisioned so
deep a surgery on usbcore.
> 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.
Regards
Oliver
-------------------------------------------------------------------------
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
