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. > Isn't there something odd about skb merged by receive offload? > I've not entirely sorted out the full structure of skb. There has been some work to allow for using both the frags array and frag list, but a driver will not see such an skb if it does not advertise the NETIF_F_FRAGLIST feature. 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 linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
