Hi Alan,
You are very close to understanding me.
If my understanding of the n_tty.c code is correct it will
only start throttling when there is TTY_THRESHOLD_THROTTLE
i.e. 128 bytes left in the n_tty ring buffer this is a very low limit
for my driver. This means
that if I try to do a tty_flip_buffer_push of
of a tty buffer larger than 128 bytes when the threshold
is reached I will lose data. My urb buffers are 4k in
size 2 buffers of this size up to the tty layer in a row 
quickly I believe I'll lose data in the n_tty layer.

Alan Cox wrote:
quoted text
> O> Alan you'll notice I'm calling tty_flip_buffer_push(tty)
>> i.e. flush_to_ldisc every 32 bytes as
>> TTY_THRESHOLD_THROTTLE in /drivers/char/n_tty.c is
>> only 128 bytes & I need to get unthrottled before
>> I lose characters it would be nice if the tty layer
>> could set the size of the throttle/unthrottle parameters
>> & the size of the n_tty ring buffer.
> 
> I don't really follow what you are trying to do here. You have two layers
> of buffering to consider
> 
>    Driver -> | tty buffer queue (64k) | n_tty - internal queue | user
> 
> 
> And it is when the internal queue gets full that we call throttle not
> when the 64K of tty buffering is full.
> 
> So you really shouldn't see a problem unless you have many Kbytes of USB
> requests floating around to consume all the buffering even after the tty
> is throttled.
> 
> As to the robustness - the USB tty code is generally pretty bad in this
> area so hso won't be any worse. Probably it is sufficient to keep an eye
> on what is in flight and when an URB completes don't just reissue it but
> reissue any others that didn't get posted due to errors.
> 
> The only other case you then have to trap is the nothing could be queued
> case which should never happen and I guess if you are passionate about
> robustness would need a timer.
> 
> Alan


-- 
best regards,
D.J. Barrow
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html