Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1190016

Re: [PATCH] Fix data loss in cdc-acm

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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