On 07/22/2015 04:40 AM, Oliver Neukum wrote: > On Tue, 2015-07-21 at 12:45 -0400, Peter Hurley wrote: >> Let me know if you need help instrumenting the tty buffers/throttling >> to help figure out what the actual problem is. >> >> Regarding the patch itself, I have no opinion on the suitability of >> simply not resubmitting urbs. However, that is exactly how the >> throttle >> mechanism works, and the tty buffer API is specifically designed to >> allow drivers to manage flow via that interface as well (especially >> for high-throughput drivers). > > Could you please expand on how this is supposed to work? > For once how does one learn that room is available again?
There are basically 3 mechanisms for managing rx data: 1. Allocate space when the data arrives; drop data if no space is avail and indicate buf_overrun. This is what most drivers do. 2. Allocate space when the data arrives; try to buffer uncopied data and resubmit the data later. Some high-throughput drivers (in the wild) do this (but less so now that the tty buffer space is configurable). 3. Pre-allocate space _before_ the data arrives (with tty_buffer_request_room()); this is applicable to subsystems which know how much data can be in-flight at any one time. This guarantees that when rx data arrives buffer space is available (since it has already been allocated). Drivers that use method 2 typically attempt to recopy the buffered data when either new data arrives or @ unthrottle. I've seen others use deferred work as well. AFAIK no driver/subsystem is using method 3 for guaranteed delivery of in-flight data, but it seems ideally suited to usb serial. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
