Alan Stern wrote: >> > 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. One other difference is that the higher you raise it, the fewer the number of applications that will try to exceed it. Then, if there are bugs in the splitting code or in handling pending operations, they are less likely to be noticed early. Regards, Michael -- 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
