Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1190016
| From | Peter Hurley <peter@hurleysoftware.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] Fix data loss in cdc-acm |
| Date | 2015-07-22 16:40 +0200 |
| Message-ID | <pP3lD-19S-7@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <pOn34-7R5-3@gated-at.bofh.it> <pOnFM-nL-23@gated-at.bofh.it> <pOBSp-415-5@gated-at.bofh.it> <pOITU-5xi-1@gated-at.bofh.it> <pOXSV-1JX-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] Fix data loss in cdc-acm Sven Brauch <mail@svenbrauch.de> - 2015-07-19 23:50 +0200
Re: [PATCH] Fix data loss in cdc-acm Johan Hovold <johan@kernel.org> - 2015-07-20 19:30 +0200
Re: [PATCH] Fix data loss in cdc-acm Sven Brauch <mail@svenbrauch.de> - 2015-07-20 20:10 +0200
Re: [PATCH] Fix data loss in cdc-acm Oliver Neukum <oneukum@suse.com> - 2015-07-22 10:50 +0200
Re: [PATCH] Fix data loss in cdc-acm Peter Hurley <peter@hurleysoftware.com> - 2015-07-22 16:40 +0200
Re: [PATCH] Fix data loss in cdc-acm Oliver Neukum <oneukum@suse.com> - 2015-07-22 17:10 +0200
Re: [PATCH] Fix data loss in cdc-acm Sven Brauch <mail@svenbrauch.de> - 2015-07-23 01:00 +0200
Re: [PATCH] Fix data loss in cdc-acm Peter Stuge <peter@stuge.se> - 2015-07-27 12:10 +0200
csiph-web