Re: gadget file storage with variable maxpacket

On Nov 14, 2007 3:36 PM, Alan Stern <[email protected]> wrote:
> On Wed, 14 Nov 2007, ilya wrote:
>
> > wireless usb will be introducing a lot of new control requests, flow
> > control [ie: stalling endpoints should be the last resort because in wusb
> > you can NAK and the host will wait for a special device notification to send
> > a transfer token instead of constantly polling as in wired usb], association,
> > etc. i think a lot of these things could be handled by the controller driver,
> > but there are a lot of other stuff that could be standardized and handled
> > by the "gadget" client side.
>
> Do any of these things affect wired USB?

not at all, 2.0 is ok. but but wait 'till 3.0, i know it will have
flow control similar
to wusb and variable maxpacket sizes too. although this is long time from now,
so lets worry about wireless first.

> > i figured out how to change the maxpacket in the descriptors, what
> > i am having problem with is queuing-in of the requests and
> > writing to disk. the fs gadget tends to queue in requests of size 512
> > during writes/reads of, for example 64k, to either stay in the page
> > boundaries or because it rounded down to stay in the block boundaries.
>
> What do you mean?  Are you talking about request lengths for USB
> transfers?  For disk reads (IN to the host), the request length is the
> same as the amount read from the disk, which is limited only by the
> buffer size (the default is 16 KB).  For disk writes the situation is
> similar.
>
> Yes, some requests are smaller in order to align with page boundaries.
> But once the alignment has occurred, the following requests should all
> be as large as possible.

i was talking about the lengths of USB transfers and these alignments
are what causing the problem. it was ok for high speed because the
maxpacket is the same as the block size [if i am correct?] but with larger
max packets, and especially with maxpackets of non multiples of 512,
there is a problem. see my response below.

> > i, on the other hand, will be doing transfers of maxpacket 2048 so
> > now i either have to concatenate transfers in my code, or tweak fs gadget
> > to queue in requests with sizes of maxpacket multiples. i had
> > success doing this for reads but not so much for writes.
>
> You don't have to tweak anything.  Just because maxpacket is 2048, that
> doesn't mean all your transfers have to be 2048 bytes long.  There's
> nothing wrong with short packets or with transfers that extend across
> multiple packets.
>
> (At least, that's true for wired USB.  I don't know much about wireless
> USB; perhaps it's different.)

so if it is a single-packet transfer, then yes, there is obviously nothing
wrong with short packets. i am concerned with transfers that are made
up of multiple packets. with INs, if you blindly send out the data that the
gadget queues-in [and have maxpacket greater then 512] you will end up
sending out a short packet in the middle of this multi-packet transfer and
short packet = end of the transfer. so for this case one would have to
make sure to concatenate any requests that are less than maxpacket in
order not to terminate a transfer prematurely. but now how does the controller
driver know that this request is part of a multi-packet transfer and that
request is actually a single transfer with size of less than maxpacket; it
would have to look at the mass storage commands, which is the file storage
gadget's job. with OUTs it is inconvenient because most hardware use
buffers that are size of, or multiples of, maxpacket; so with these short
packet requests you now have read out a buffer in multiple requests,
which adds overhead and is more prone to errors/problems.

-- ilya

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel