On Tuesday 27 January 2009, David Brownell wrote: > On Tuesday 27 January 2009, Inaky Perez-Gonzalez wrote: > > The problem of having a single URB per s/g node is the overhead. When > > you need to insert headers in the middle of a data stream (for example) > > every so many bytes, the URB overhead starts to be felt. > > That overhead is linear in the number of bytes, not in the > number of URBs. One URB of 64KB; or sixteen of 4KB; same > overhead. Scatterlists are irrelevant. Scratch -- I don't think I understand why they become irrelevant. If I have a data block of X bytes to be sent and the underlying hw requires it be broken up in chunks of Y with H of headers prefixed to each chunk, then I get to have 2 * (X + Y - 1) / Y sg nodes, which yes of course, is linear on X (one node for each header, one for each chunk). But what we mean is that we give the URB the sg list instead of having a single URB per sg node. > > Allocation is > > easy, but initialization and the rest really make it messy. > > That sounds to me like "<this implementation> sucks". A lot. But is what the spec says :( And actually the code sucks even more. Trust me, I wrote it. > If the hardware doesn't let you provide header and > data in separate chunks, it's a hardware design bug. > And you're stuck with otherwise needless copies in > all I/O paths, plus work managing bounce buffers. > Lose, no matter what the software stack does. It does, I think we are talking about something different. Currently we do the bounce buffers to avoid having 2 * (X + Y - 1) / Y URBs allocated and managed, which after trying, ended up being much more of a pain. > If the hardware *does* let them be in separate > chunks, then there's no reason not to have the > loop which chunks buffers into a list of DMA > transfer descriptors (TDs) handle those headers. > Heck, just have a header per TD so there's only a > single pool to manage. Win -- it can be zerocopy > in terms of the buffer provided by the driver. Isn't this almost the same that I asked above? Sorry, really confused. -- Inaky -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
