Am Montag, 2. Juli 2007 schrieb Alan Stern:
> 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.
But if resources are bound to an endpoint the HCD must generate an
interrupt when the resources are no longer in use so they can be reused.
> 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?
Not that I know of. Matthew?
> > > 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.
If we do a full preallocation for the worst case, one code path will do.
> > 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.
Why? What is preallocated is already available. The question arises
with dynamic allocations.
> > > > 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?
Why? Or rather if the amount is determined according to the current
granularity or the granularity in the worst case, you associate with the
URBs. If you allocate less then you cannot associate with the URBs
as you don't have enough resources.
> 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, indeed I am not sure that preallocation is the way to go for the
storage driver. I care more about cdc-acm, the serial and the video
drivers.
> > 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.
True, but I could force a worst case.
> 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?
Obviously the capabilities advertised to the SCSI layer would need to be
limited. I am not sure that this is a good idea.
> > > 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?
I am not. I want to change it, not disunite it.
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
