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