Re: Is usb_buffer_alloc a generic URB buffer allocator ? (was Split Bulk Transfers)

On Wednesday 16 May 2007, Alan Stern wrote:
> On Tue, 15 May 2007, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > following the discussion about the split bulk transfers, Alan Stern and
> > David Brownell told me I shouldn't use usb_buffer_alloc as a generic
> > purpose URB buffer allocated. However, Documentation/usb/dma.txt
> > contradicts this. Should the documentation be fixed, or can/should
> > usb_buffer_alloc be used to allocate URB buffers ?
>
> It's difficult to give general advice, since the performance will vary
> according to the platform and the usage.
>
> If a buffer is going to be used once and then thrown away, I think
> there's not much advantage to usb_buffer_alloc().  Although on some odd
> platforms that may not be true, it should be true on the vast majority.

Ok. A driver should obviously not allocate a lot of DMA cache coherent memory 
if it's not going to use it. For buffers that are allocated at initialisation 
time and not used often, usb_buffer_alloc() should not be used.

> If a buffer is going to be used many times, then usb_buffer_alloc()
> might give improved performance.  Again, that depends on the platform
> and the type of memory accesses involved.
>
> The tradeoffs are hard to assess because they involve a lot of
> variables: How responsive is the IOMMU, does the cache do
> bus-snooping, will there be many accesses to uncached memory, and so
> on.

There's something I don't get. The documentation states that USB buffer memory 
should be allocated using kmalloc or get_free_pages. This means that 
allocated memory will be physically contiguous. However, not all controllers 
should require that. There are, from what I can tell, three classes of USB 
host controllers:

- PIO host controllers don't use DMA at all, and should thus not require 
physically contiguous memory. The device dma_mask field is set to 0, and 
usb_hcd_submit_urb doesn't allocate DMA mappings for URB buffers when using 
such a controller.

- DMA-able host controllers without hardware scatter-gather require physically 
contiguous memory. For those controllers, usb_hcd_submit_urb allocates DMA 
mappings if the URB buffers haven't been mapped already (URB_NO_*_DMA_MAP 
flags not set). usb_hcd_giveback_urb unmaps the buffers if they have been 
mapped by usb_hcd_submit_urb. As those controllers require physically 
contiguous memory, kmalloc or get_free_pages must be used.

- DMA-able host controllers with hardware scatter-gather don't require 
physically contiguous memory. EHCI controllers seem to have scatter-gather 
capabilities. For those controllers, pressure on the memory allocator could 
be lowered by implementing scatter-gather.

USB device drivers currently either allocate URB buffers with 
kmalloc/get_free_pages or call usb_buffer_alloc. When using the former, the 
DMA mapping is created and deleted at URB submission/completion. When using 
the later, DMA mappings are created once and kept for the entire life of the 
buffer.

I suppose we should keep kmalloc/get_free_pages for buffers that are seldom 
used. From what I've seen so far, usb_buffer_alloc would help for buffers 
used for isochronous or bulk streaming, where the same URBs are submitted 
again and again. That would remove the DMA map/unmap overhead.

Shouldn't we implement scatter-gather for EHCI (and possibly other) 
controllers ? Is it planned ? We would then need a generic URB buffer 
allocator, as the device driver should not care about what kind of memory the 
USB host controller needs. The allocator would be passed a parameter to 
DMA-map the buffer for streaming bulk/isochronous transfers.

These are just my 2 cents, as I'm not too familiar with the USB stack 
implementation (but this is going better with every mail to/from the 
list :-))

Best regards,

Laurent Pinchart

-------------------------------------------------------------------------
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