> Also I believe some virtual usb uart (3G dongle, cdc-acm) that use higher rate
> (more than 10 Mbps) will have the same problem. They will fill the buffer very
> quickly.
PPP doesn't use throttling so those dongles which are use modem emulation
will flow control at the IP level which is probably better anyway.
> For example the "USB: cdc-acm: Prevent loss of data when filling tty buffer"
> patch may be changed to something like :
>
> /* throttle device if requested by tty */
> spin_lock_irqsave(&acm->read_lock, flags);
> acm->throttled = acm->throttle_req;
> if (!acm->throttled && !acm->susp_count && !tty_is_throttled()) {
> spin_unlock_irqrestore(&acm->read_lock, flags);
> acm_submit_read_urb(acm, rb->index, GFP_ATOMIC);
> } else {
> spin_unlock_irqrestore(&acm->read_lock, flags);
> }
Except this now races the handling in the throttle/unthrottle events. In
particular you could have an unthrottle queued to occur such that by the
time it occurs we've throttled again, plus the ldisc may be quite slack
in signalling it to the tty layer.
For that example a second approach would be to provide
static int tty_buffer_room(struct tty *tty)
{
return 65536 - tty->buf.memory_used;
}
and you could then buffer against the queue size, which is easy to
monitor in IRQ state, but would mean that you'd need to be sure that you
always had some buffer posted or some way to recover from the no buffers
case (eg adding
if (tty-ops->buffer_free)
tty->ops->buffer_free(tty)
to tty_buffer_free())
At that point it is throttling against the queue that is handled in
interrupt space.
Care to prototype those bits in your tree and see if it sorts your use
case ?
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
