Re: patch to shift memory allocations to usb_alloc_urb()

Am Freitag, 29. Juni 2007 schrieb Alan Stern:
> On Fri, 29 Jun 2007, Oliver Neukum wrote:
> 
> > Hi,
> > 
> > this proved harder than it looks like. I can use cdc-acm over ohci with
> > this patch. So what do you think?
> 
> It tries to do an awful lot all at once.  A good place to start would 
> be to use separate allocation for the Iso packet structures.  This 
> could be a simple standalone change.

OK.

> Have you looked at Marcel's URB-allocation routine?  We seem to be 
> growing a whole variety of them at the moment.  Maybe some of them can 
> be combined.

IMHO, this is because they are two fundamental ways to use URBs.
Either you see them as describing a "packet" to be thrown away after
use or as a "pipeline" to be kept until the connection is closed. In the
latter case you want to keep all resources. Marcel's patch goes for the
first model.
 
> There's a more fundamental problem with your approach, though.  You
> can't just allocate the TD's, ED's, and whatnot right alongside the
> URB.  These data structures generally have to be located in
> DMA-consistent memory (or is it "DMA-coherent"? -- I can never remember
> the distinction).  That's why the HCDs use DMA pools for them.

True, but that does not prevent me from allocating them at the same _time_
and keep them around until the URB is freed.

> Another problem involves conflicts with disable_endpoint.  HCDs use
> that callback to deallocate their endpoint data structures (EDs for
> OHCI).  But if you're allocating space for the ED along with the URB or
> trying to associate the two of them somehow, you would end up in
> peculiar circumstances -- like when the endpoint has been disabled and
> its ED freed, while its URBs are all killed but still allocated and
> available for use.

How is that different from the current situation? Perhaps the ed should
be refcounted and disable_endpoint could orphan them.

> Do you really want to bind URBs to specific endpoints?  There must be
> places where drivers use a single URB to carry out multiple functions,
> talking to different endpoints.  Certainly usb-storage does that.

Yes, I want to do that. Or rather I see no sane way to otherwise determine
the maximum amount of resources needed. Driver will require changes
anyway.

> Perhaps a better approach, if you insist on pre-allocation, would be at 
> the HCD level.  There could be an HCD routine that would reserve space 
> sufficient for a certain number of URBs with a certain total transfer 
> length on a specific endpoint.  Then that space would be available for 
> any URB a driver wants to submit -- it wouldn't be coupled to a single 
> URB.

No suppose to drivers needing two URBs each and each one would get
only one of the two reserved URBs. Or you reserve 4 URBs in that case.
Then you can go to a full association anyway.

	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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel