On Fri, Jun 26, 2009 at 7:29 AM, Alan Stern<stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 25 Jun 2009, Steve Calfee wrote: > >> I think having a stop on short mechanism is a very good idea. If the >> devio would just abort all pending transfers on the endpoint, on this >> and all other urbs, we don't need a USBDEVFS_UNBLOCKEP call. The user >> app knows the transfer is done, the next submission should start >> another (possibly short transfer cancelled) IN urb. > > As Daniel pointed out, this won't work. Think about what happens when > userspace submits several independent transfers (each of which might be > broken up by libusb into multiple URBs), where a short packet should > terminate only the current transfer, not all of them. > 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. Future apps will have to either add your ioctl to restart the queue, or resubmit cancelled transfers depending on the scheme. > >> For lower overhead and higher transfer rates, userspace often asks for >> multiple packets. There is the current arbitrary maximum xfer size of >> 16*1024 bytes per urb. However, nothing stops an app from asking for 4 >> urbs of 16K and then waiting. It think that now the short packet will >> end the urb, but what of the other pending urbs? Alan's suggestion >> will fix that. > > The problem is that sometimes those other pending URBs should be > aborted and sometimes they shouldn't be. We could complicate the > scheme by telling usbfs which ones to terminate. But it might be > easier to take Daniel's suggestion and let the kernel, not libusb, do > the splitting up. > 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. 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. 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. Regards, Steve -- 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
