On Fri, Apr 09, 2010 at 02:12:29PM +0100, David Vrabel wrote: > Sarah Sharp wrote: > > Recently Ramya tried to enqueue a very large transfer to the xHCI driver > > and filled the endpoint ring for that bulk endpoint. Because of that > > I've been looking at doing dynamic ring resizing. I've run into a > > slight problem. > > Do you really need to dynamically resize the ring? Would it be > sufficient to add to the ring only the elements that fit and add the > rest as the first ones complete? That's somewhat more painful than expanding the ring when I'm trying to accommodate one URB with a very large sglist. I would have to enqueue some of it, figure out where the max packet/burst size boundaries are to partition it correctly so the device doesn't get confused, and then enqueue the rest of it when I get an event back from the hardware saying that part of the urb's sglist had transferred. That option would probably effect the cancellation code and TD list code. The upside of expanding the ring is that I will probably only do it once for the first large transfer, and then the driver will always be able to fit the large URBs on the ring. That's if I expand the ring and then don't bother to shrink it back. I suppose it could be a waste of memory if the driver enqueues one very large transfer and then enqueues very small transfers from then on. The endpoint ring segments are only 1K though. Most people don't plug in more than 5 devices with 3 endpoints each, so that's only 15K vs. 30K-45K of DMA'able memory. Another option would be to expand the default ring segment size, rather than the number of segments. The ring segment size could be expanded to 2K or 4K or even bigger. I'd like all the ring segment sizes to be the same, because the streams code relies on a radix tree to map DMA addresses to stream rings, and the key is the DMA address right shifted by the size of the segment. The downside to increasing all the segment sizes is that most device drivers only enqueue small transfers, and control endpoint rings rarely have more than 3 TRBs on them at a time. Sarah Sharp -- 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
