On Mon, Nov 18, 2013 at 03:41:00PM -0000, David Laight wrote: > > > > -----Original Message----- > > From: Ben Hutchings [mailto:bhutchings@xxxxxxxxxxxxxx] > > Sent: 18 November 2013 15:03 > > To: David Laight > > Cc: Alan Stern; Sarah Sharp; netdev@xxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx > > Subject: Re: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst. > > > > On Mon, 2013-11-18 at 09:48 +0000, David Laight wrote: > > > > > But the minimum fragment size is (probably) 4k. > > > > > For the network stack an OUT transfer might have a lot (and I mean lots) > > > > > of fragments (there may be constraints, and linearising the skb is a option). > > > > [...] > > > > > > > > The maximum number of fragments in the skb is going to be 17 (including > > > > the 'head' area). (I'm ignoring NETIF_F_FRAGLIST which is not normally > > > > supported by physical device drivers.) > > > > > > > > I don't know how many fragments that can end up as, at the USB level. > > > > > > If you assume that every fragment crosses a 64k boundary that would be 34. > > > OTOH I've not seen a fragment of a 64k TSO send crossing a 32k > > > boundary, and I think the 'head' area is constrained to be part of > > > a single (4k or larger) page. > > > > I don't know that it's possible at the moment, but I wouldn't recommend > > relying on that. > > The xhci (USB3) hardware supports SG, but a non-obvious alignment restriction > applies at the end of a ring segment. In effect this means that the number of > fragments mustn't exceed the size of the ring segment. > It would make the xchi driver simpler if excessively fragmented requests > could just be bounced. > Since ring entries are 16 bytes there isn't much reason to not use a 4k > 'page' for a ring and have (almost) 256 ring slots. > (The code currently uses multiple ring segments with 63 usable slots.) > > Looks like skb are constrained enough that a sensible limit can be applied. > > The other likely generator of fragmented requests is the mass storage code. > Most likely for dd(1) with a large block size. The xHCI driver can limit the number of sg-list entries through hcd->self.sg_tablesize. It's currently set to ~0, which is "however many entries you want. You could set that to the number of TRBs in a segment (minus one for the link TRB). The usb-storage and uas drivers currently use sg_tablesize. Could the network stack be taught to use sg_tablesize as well? (Also, usb-storage aligns the block sizes to 512K, which explains why we've never had an issue with TD fragments with that driver.) 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
