On Thu, 8 Apr 2010, 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. > > In xhci-pci.c, David Vrabel set hcd->self.sg_tablesize to > (TRBS_PER_SEGMENT - 1), or 63 entries. The USB storage driver currently > sets the Scsi_Host->sg_tablesize based on the hcd's table size, which > limits the number of scatter-gather entries. So even if I add more > segments to the rings, the driver will never enqueue a transfer with > more than 63 sglist entries. > > If I want to dynamically expand the rings to include multiple segments > and thus support more sglist entries, what should I set > hcd->self.sg_tablesize to? It is supposed to be the maximum acceptable size. If you dynamically expand the ring then there is no maximum, so set it to the largest value that will fit. > If I set it to something large (like EHCI > sets it to ~0), can I reject transfers if I run out of memory while > allocating new ring segments? Should I use -E2BIG or -ENOMEM? -ENOMEM. However there's nothing wrong with capping things at some reasonable size. If someone tries to submit a request that violates the driver's specified limit, it's their own fault. Was Ramya's very large transfer a single bulk URB? Did it use scatter-gather? Alan Stern -- 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
