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.
> > > 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.
Yes, though the sg api would probably need to change.
> > > 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.)
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.
> > > 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.
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.
Furthermore every driver that does a resubmission in interrupt
profits. We have something of a blind spot here. Driving a device
at hardware speeds is not very good if it sucks up too many cpu cycles.
> 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.
> > - 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?
Avoiding memory allocations is the simplest way to avoid ENOMEM for
sure.
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
