[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1384565904.29151.66.camel@bwh-desktop.uk.level5networks.com>
Date: Sat, 16 Nov 2013 01:38:24 +0000
From: Ben Hutchings <bhutchings@...arflare.com>
To: David Laight <David.Laight@...LAB.COM>
CC: Alan Stern <stern@...land.harvard.edu>,
Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
<netdev@...r.kernel.org>, <linux-usb@...r.kernel.org>
Subject: Re: [PATCH] usb: xhci: Link TRB must not occur with a USB payload
burst.
On Wed, 2013-11-13 at 16:58 +0000, David Laight wrote:
[...]
> > > > > You can split a bulk TD on a 1k boundary and the target won't know the
> > > > > difference.
> > > >
> > > > The target won't know the difference, but the host will. Here's an
> > > > example: Suppose the driver submits two URBs, each for a data-in
> > > > transfer of 32 KB. You split each URB up into two 16-KB TDs; let's
> > > > call them A, B, C, and D (where A and B make up the first URB, and C
> > > > and D make up the second URB).
> > >
> > > I was thinking about OUT transfers, IN ones are unlikely to be badly
> > > fragmented.
> >
> > Maybe not for the network stack, but OUT and IN end up equally
> > fragmented for the storage stack.
>
> 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.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists