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. > Allocation is > easy, but initialization and the rest really make it messy. That sounds to me like "<this implementation> sucks". 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. 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. - Dave -- 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
