Re: Split bulk transfers

On Wed, 9 May 2007, Laurent Pinchart wrote:

> I wasn't aware of those functions. Just to make sure I get this right, am I 
> right to say that URB buffers should be allocated as contiguous cache 
> coherent physical memory (using usb_buffer_alloc, which in turns call 
> dma_alloc_coherent for big DMAable buffers) or as normal memory using 
> scatter-gather routines ?

I agree with what Dave said.  For your purposes, you should use plain old 
kmalloc or get_free_pages.  You don't need cache-coherent buffers or 
scatter-gather mappings.

> I currently allocate big bulk buffers using usb_buffer_alloc, which puts a lot 
> of pressure on the memory allocator. Using scatter-gather mappings would 
> help. However, if I'm not mistaken, the usb_sg_* routines are designed for 
> synchronous use (with usb_sg_wait), and thus can't be used for streaming 
> data.

Correct.  But remember, with streaming URBs you don't need terribly big
buffers.  Just be sure to submit enough URBs to make up for interrupt
latency; the size of each URB's buffer doesn't matter very much.  If your
pipeline can hold 20-ms worth of data, it should be fine.  And that's a
generous estimate; 5-ms worth would almost always be enough.


> Actually I'm not. I submit a few URBs to get high throughput. Even with 
> several URBs, memory usage is smaller than with a single payload-sized URB.
> 
> Why do I need to set URB_SHORT_NOT_OK on all but the last URB ? As the actual 
> payload size isn't known (only the maximum payload size is known), a short 
> packet can be received at any time. The next URBs will be filled with the 
> next payload, right ?

For streaming payloads it doesn't matter so much.  But for example, if you
had decided at the start which URB should belong to which payload, then a
short packet on an intermediate URB could cause a problem -- all the
following URBs would be shifted back to the next payload.  Or if you were
careless, you might end up with a single URB containing data from two
different payloads.

If none of that matters then there's no need to use the flag.


> > If it doesn't send the extra 0-length packet, then you have to make sure
> > that your last URB's length is exactly the right amount to make up a
> > maximum-sized payload.
> 
> Otherwise the last URB will be filled with packet from the next payload, 
> right ?

Right.

> > If it does send an extra 0-length packet then your last URB needs a larger
> > length, so that the 0-length packet will be received properly.
> 
> If the last URB doesn't have a larger length, won't the 0-length packet be 
> received by the next URB, making the USB stack call the completion handler 
> with a 0-length URB ?

Yes.  You would then think it was a 0-length payload.

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