On Wed, 16 May 2007, Pete Zaitcev wrote:
> > What I would suggest is that when you allocate an URB and DMA'able memory,
> > you
> > have to specify which pipe {CONTROL, BULK, INTERRUPT or ISOC} it belongs to.
> >
> > What do you think?
>
> Just a side note, we are trying to move away from the pipe as a concept,
> because it turned out to be ficticious despite being spelled out in the
> spec. The real object to which you talk in the device turned out to
> be the endpoint, and the spec is deceiptive. So, let's assume that you
> want a kind of per-endpoint preallocation.
It's worth pointing out that there already are drivers which
preallocate URBs and memory buffers and then share them among multiple
endpoints. One example is usb-storage.
We have discussed in the past the notion of making URB allocation
per-bus. That would have less impact; not too many drivers share URBs
among different devices (although I think the Bluetooth driver does).
The advantage is that the allocation could then automatically
incorporate an HCD-private area; currently this has to be allocated
separately every time an URB is submitted.
> > The reason is that in the new USB stack on FreeBSD, the USB transfer
> > descriptors are allocated along with the data-buffer, so that when you
> > unsetup an USB transfer, absolutely all memory related to a transfer is
> > freed. This also has a security implication in that when you have
> > pre-allocated all buffers and all USB host controller descriptors, you will
> > never get in the situation of not being able to allocate transfer
> > descriptors
> > on the fly, like done on Linux.
It might make more sense to dedicate the transfer descriptors to the
endpoint and not to any particular transfer. This can be done entirely
within the HCD code. However it would not completely solve the problem
of needing to allocate descriptors on the fly, although it would reduce
the impact.
> The requirement for massive on-the-fly allocations is a part of Linux
> stack that bothered me for a long time. This is especially annoying
> for block devices when pressure builds up in the VM, and dirty data
> has to be written out to a block storage device attached by USB.
> This is somewhat analogous to the problem which exists with NFS.
I don't see how either of these scenarios would be affected. Whether
you do all the other allocations when the URB and its buffers are
allocated or you wait until the URB is submitted, the memory pressure
would still be just as bad.
> I suppose we could do one last effort:
> - redefine usb_buffer_alloc to allow for endpoint argument
> - implement methods in HCDs to allocate and free QPs and xxx_priv
> - spell out in documentation very clearly that drivers should
> NOT use these facilities by default and only use them when
> memory pressure invokes these URBs
>
> This is something which, I think, only Greg Kroah can decide on doing
> or not doing.
I am not in favor of such a large change.
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
