> -----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. David ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
