On Fri, 26 Jun 2009, Steve Calfee wrote: > Hi Alan, > > Actually, either scheme can work. Aborting all packets pending would > not break any existing apps because if they are using the short packet > ending they can only be doing single transfer urbs right now - due to > the current devio.c limitations. In other words, it wouldn't make things any worse than they are now. > Future apps will have to either add your ioctl to restart the queue, > or resubmit cancelled transfers depending on the scheme. > Ok, the main difference between the two approaches is > > 1) With the "single URB abort" the kernel needs to know how big the > entire transfer is (and therefore must allow much bigger transfers if > we need bigger than 16k terminated transfers), and can kill a single > transfer on a short packet. Yes. It's tedious to code, because it would involve copying a lot of little memory buffers and setting up a scatter-gather list to keep track of all of them. There's also an issue of running out of kernel memory. I don't know how to judge how important that might be. We didn't face the problem before because libusb-0.1 submitted the chunks one-by-one (good for memory usage but bad for throughput). How does libusb-1.0 behave? If it submits the broken-up URBs all at once then we already face the out-of-memory problem. On the other hand, if it submits them one-by-one then it shouldn't have any trouble stopping when a short packet is received. > OR > > 2) With the "abort everything" pending on an endpoint method the clean > up after a transfer termination is left to the userspace app. And it > does not require changing the user urb size limitation. > > The kernel being involved in 1 allows higher bandwidth transfers (for > short packet terminated transfers), because multiple transfers can be > queued that use the short packet termination. The gain will not be as > high as it might seem because the user app still has to call the > kernel with the "restart" ioctl USBDEVFS_UNBLOCKEP you propose. That's not entirely true. Higher bandwidth will be obtained in the case where no short packet is received. This may be the normal situation, depending on the usage. Also, in order to solve Daniel's problem I've got another scheme that doesn't require the UNBLOCKEP ioctl. It would yield higher bandwidth always. (The idea is to add another USBDEVFS_URB flag to mark the first URB of an async transfer. When usbfs sees this flag it will stop aborting URBs and unblock the endpoint.) > The > app could just as well start the next transfer at that time as would > be required for 2. > > Actual benefit evaluation require actual measurements. I believe > keeping the kernel/app interface simple is better. However, you are > implementing it, either approach is better than the current situation. Complexity of the interface depends on how you look at it. Keeping the kernel part simple involves making the userspace part more complicated, and vice versa. On the other hand, if all the complexity is wrapped up in libusb then most people won't care about it. Alan Stern -- 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
