On Wednesday 28 January 2009, Alan Stern wrote: > I've been too busy to take part in this discussion (upgrading to Fedora > 10 was a disaster because the X server doesn't work on my machine) -- > there hasn't even been time enough in the last few months to read > through much of the USB 3.0 spec. So I have only a few comments to > add... Which is why I encouraged a high-level description of the issues first. I don't think many folk have had a chance to read it. > On Tue, 27 Jan 2009, David Brownell wrote: > > > > The problem is that I saw significant performance improvement with USB > > > 3.0 prototypes when I pushed the scatter gather list down to the xHCI > > > HCD. The xHCI data structures are just set up in such a way that > > > queuing a list of scatter gather entries is just natural. > > > > That's a discussion we can have more producively when > > everyone can see what those xHCI data structures are. ;) > > > > Are they really that different from EHCI or OHCI? They > > support queues too. The generic model is "queue" ... not > > scatterlist, which isn't used much outside the block layer. > > The main difference being how DMA is handled. Doesn't answer the question. :) > Also, "queue" is _too_ > generic -- it doesn't express the idea that a bunch of buffers may all > belong to a single logical transfer. So far we've handled that with > the URB_NO_INTERRUPT kludge, but I think a different approach would be > better. (For example, URB_NO_INTERRUPT isn't implemented properly in > usbfs.) NO_INTERRUPT is a performance hint, in support of interrupt mitigation, not a semantic dictum. EHCI can do pretty complete mitigation; OHCI, only partial. Recall that it's used with network packet queues too, where they really must *not* be coupled to packet boundaries. > Note: As far as I can see, this notion applies only to bulk transfers. Which notion ... scatterlists? > ISO transfers already have a sort-of scatterlist implemented, Restricted to one buffer; each packet boundary is specified. The issue Sarah raised involves submitting several buffers (to support bursting) where packet boundaries don't matter. > control > transfers are generally limited by HCDs to a single contiguous buffer > (will this need to change for USB 3.0?), Shouldn't. That's purely an implementation shortcut; nobody ever issues large (4+ KB) control transfers, so no HCD needed to bother supporting them. (And they can get very messy...) > and interrupt transfers don't > usually need to send all that much data. Maybe they could benefit from > this idea too, I don't know. I don't think there's a current use case. > In general, I agree with the viewpoint that pushing the scatterlist > handling down into the HCDs would be an improvement. Whether this is > done by actually using scatterlists (which already exist) or some other > data structure (which might be better suited to our needs) is a > separate issue. OK. > > So for example I've seen individual scatterlists > > of nearly a megabyte get sent to EHCI, which works > > on them and then issues a single completion IRQ. > > There are several limitations to the current implementation. The two > most notable are: It can't run asynchronously, and it doesn't directly > map buffers from userspace. Async behavior wasn't a design goal. If usb-storage is ready for it, hack away! :) Re userspace buffers, there are other messages on that; IMO, that should be handled by a different set of calls that pin the userspace buffers and morph them to kernel ones appropriately. > A new implementation will certainly have its own issues. In > particular, I'm thinking of the requirement that every buffer in a > transfer (except the last) must be a multiple of the maxpacket length. > The block layer currently has no way to express this requirement. But has that been a real issue so far? Or its sibling constraint on alignment? - Dave -- 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
