Messages in this thread | ![/](/images/icornerl.gif) | | From | Inaky Perez-Gonzalez <> | Subject | Re: Scatter-gather list constraints | Date | Thu, 26 Jun 2008 15:39:25 -0700 |
| |
On Thursday 26 June 2008, Alan Stern wrote: > On Thu, 26 Jun 2008, Perez-Gonzalez, Inaky wrote: > > > For WA, when we get a buffer to be sent from a URB, it has to be split > > in chunks, each chunk has a header added. So we end up with a list of > > chunks, most of them quite small. Each requires a single URB to send. > > resources galore. > > > > If we could queue all those, the overhead would be reduced to allocating > > the headers (possibly in a continuous array) and the sg "descriptors" > > to describe the whole thing. > > > > However, the alignment stuff somebody mentioned in another email in this > > thread might cause problems. > > > > At the end it might not be all that doable (I might be missing some > > subtle isssues), but it is well worth a look. > > > > >Note that usbcore already contains a scatter-gather library. > > >(Unfortunately the library is limited in usefulness because it needs to > > >run in process context.) > > > > And the overhead of one URB per sg "node" kills it's usability for > > WAs. > > For this case (lots of small chunks making up a single URB), using a > bounce buffer might well be the easiest solution. It depends on the > size of the URB and the number and sizes of the small chunks. There > would be a lot less overhead -- only one URB -- and one large memory > allocation instead of lots of small ones.
That's what we have right now (if I rememeber correctly); the issue is that you end up copying A LOT. I don't know, maybe I am just being overperfectionist. The data chunks (segments) can be up to (digs) 3584 [from 512, in 512 increments] if I am reading the spec right (WUSB1.0 4.5.1). Interleaving that with small chunks and change... I don't know if that much copying will end up being that good, along with the allocations it requires, etc.
-- Inaky
| ![\](/images/icornerr.gif) |