On Monday 26 January 2009, Sarah Sharp wrote: > One of the questions that came up when looking into a UASP driver was whether > the USB core API to submit scatter gather requests was adequate. My > understanding was that the driver would call usb_sg_init() and then call > usb_sg_wait(), thus blocking on the request. Right. That was a significant step up from writing one scatterlist entry at a time and then having the host wait for completion before submitting the next URB ... but it did not change the usb-storage model of not accepting multiple concurrent SCSI commands. (Didn't that restriction come from the USB Mass Storage spec?) Note that a lot of USB devices don't seem to like large requests in any case; or sometimes they don't like them coming as fast as a host can deliver them. We had to de-tune things to cope with such devices... > The new USB 3.0 MSD device class is looking at asynchronous command queueing > over USB using bulk endpoint "stream IDs". (You can read about stream IDs in > section 4.4.6.4 of the USB 3.0 spec.) The details aren't hammered out yet, but > the new USB 3.0 MSD command queueing should be very similar to SCSI command > queueing. The basic idea is to have the USB MSD driver queue multiple commands > to the USB 3.0 device and have the device notify the host when any of the > commands are done. Good. Now let's hope that the peripherals don't have the same degree of implementation flakiness we've seen so far ... > If the driver is blocked waiting on the scatter gather transfer by calling > usb_sg_wait(), it obviously can't queue any other commands. The question is, > should the driver spawn a kernel thread or a work queue or something, so that > each instance can call usb_sg_init() and usb_sg_wait()? Or should the USB core > API be changed so that the driver can submit multiple URBs with scatter gather > list pointers in them? Synch on command completion could be changed; it's never really needed to work differently. The tricky bit would be fault handling ... and to a lesser degree, how to make sure the same interface works with all kinds of HCDs (including ones that do not support DMA). I like the current model, whereby URBs deal with only a single contiguous DMA buffer. (Possibly one that's made contiguous through an IOMMU coalescing pages.) Having a uniform model is a big win ... even with the exception whereby ISO transfers split that buffer into discrete chunks. So I'd rather keep to the model whereby scatterlists are mapped to URBs outside the sight of HCDs. - 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
