[CC: list drastically trimmed] On Wed, 24 Aug 2011, Hans de Goede wrote: > >>> When I inquired about the 16kb limit in April 2010, I was told the 16kb > >>> limit was based on page alignment considerations: > >>> http://www.spinics.net/lists/linux-usb/msg29994.html > >> > >> Hmm, having an API have limits depending on some $random hardware limit seems > >> weird. Also note that as the linked mail states, submitting larger urbs is > >> not really a problem, they will just get split into multiple tds. > > > > It is however counterproductive. You always want at least one transfer to > > be being exectuted. > > Right, which is exactly why you want to submit bigger transfers, so that multiple > tds get scheduled and thus the bus is being kept busy, this is actually an > argument in favor of allowing a larger limit. No, this has nothing to do with the limit. Whether you submit a few big URBs or a lot of small ones, if the total transfer size is the same then the bus will be kept busy the same amount of time. > >> An in kernel driver can hapilly submit a bulk transfer of> 16k, so I see > >> no reason why a userspace "driver" should not be allowed to do the same? > > > > Security. Kernel space code is implicitly trusted. The problem is not > > submitting the URB but allocating the memory for the buffer. > > Sure, so we need some limit, but why 16k, that is just completely arbitrary > and well in general sucks, currently libusb has to do things like this: > > 1) split transfer into 16 kb chunks > 2) submit one by one > 3) if submission of Xth fails, cancel 0 - (X-1), ensuring already completed > ones are skipped > 4) Wait for completion, in either the error and non error scenario > 5) copy over what part did managed to complete and signal status > 6) cleanup Suppose we raise the limit to 64 KB. It will suck just as bad; libusb will then have to do things like this: 1) split transfer into 64 KB chunks 2) submit one by one 3) if submission of Xth fails, cancel 0 - (X-1), ensuring already completed ones are skipped 4) Wait for completion, in either the error and non error scenario 5) copy over what part did managed to complete and signal status 6) cleanup I don't see this being much better than the current situation. The only real difference lies in the overhead of submitting URBs. > This is I estimate all in all close to a 1000 lines of code, where as > changing the limit in the kernel would be just changing a single line, > and greatly simplify the userspace code, removing all kinds of > possible races, etc... No. It would not change the userspace code significantly. The only change would be to replace 16 with 64. > I'm not saying we shouldn't have any limit, but 16kb seems rather > arbitrary. We could for example take a look at microsofts limit and > assume that going over those is a really bad idea since most > hardware won't be tested with anything over those, see: > http://support.microsoft.com/kb/832430 > > This would give us a limit of 3344K for bulk transfers. 16 KB _is_ a rather arbitrary limit. However for transfers running at high speed or lower, I don't think it makes much difference. For SuperSpeed transfers, the overhead of splitting things up into small URBs might become noticeable. But the proper way to fix that is not to raise the limit -- and certainly not to raise it to 3 MB! The proper fix is to implement direct I/O in usbfs. 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
