Hi,
On 06/07/2012 06:59 PM, Sarah Sharp wrote:
On Thu, Jun 07, 2012 at 11:29:27AM -0400, Alan Stern wrote:
On Thu, 7 Jun 2012, Hans de Goede wrote:
So that leaves the question whom is going to code up this solution, I
see 3 possible candidates: Alan, Sarah or Hans (aka me). So any volunteers?
I'm pretty busy with other things, so I prefer not to volunteer just
now.
I'm working on adding USB 3.0 Latency Tolerance Messaging support, so I
don't have time to work on this until September (after the 3.6 merge
window and Kernel Summit). If people want this fixed sooner, I guess
Hans needs to volunteer to do it. I'm happy to review changes, of
course.
Hmm, and here I was trying to follow the well known "never volunteer" advice,
guess that didn't get me anywhere this time :)
So I'll put this on my todo list then. One question about the imlementation
though. I plan to first add a USBDEVFS_GET_CAP ioctl, I was planning on
making the results of this ioctl device independent (iow only kernel version
dependent), but with this new plan I think it may make sense to have the
results be device dependent (well really hc dependent, but the user deals
with a device).
The reason for this is the question, what to do if the hc is not sg capable,
in that case currently things will work fine when using libusb (which most
userspace apps should be using), because libusb divides large bulk transfers
into 16k urbs, using the USBDEVFS_URB_BULK_CONTINUATION flag.
Once we move to a model where devio.c can handle large bulk transfers by
dividing them into chunks itself and putting those on an sg list, and add
a capability flag for this, then what is devio.c to do if a large bulk transfer
gets submitted to a non sg capable hc? My pov on this is simple: "don't do that
you silly". IOW userspace should not be sending large bulk transfers to a non
sg capable hc. I don't think there are currently any use cases where that may
already be happening, but some libusb users may be doing just that.
So the easiest way to achieve this never happening (with libusb apps) is to make
the capabilities per device, and not set the USBDEVFS_CAP_SG flag on devices
which are connected to a non sg capable host.
A note about the USBDEVFS_CAP_SG name, I plan to also add a
USBDEVFS_CAP_UNLIMITED_URB_SIZE flag, which in essence will advertise the
lifting of the urb size limits done in this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=add1aaeabe6b08ed26381a2a06e505b2f09c3ba5
But as discussed before just because there is no limit does not mean that
submitting a 4 MB transfer in one urb is a good idea, now once we
get the sg support into devio.c, it becomes a good idea, but only on devices
which are attached to an sg capable hc.
So the idea is for the logic in libusb to be:
if (caps & (USBDEVFS_CAP_UNLIMITED_URB_SIZE|USBDEVFS_CAP_SG) == (USBDEVFS_CAP_UNLIMITED_URB_SIZE|USBDEVFS_CAP_SG))
/* do transfer in one urb */
else
/* split transfer */
Before I start working on this it would be good to hear back from you on
the sanity of these details as proposed.
Thanks & Regards,
Hans
--
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
