> re-submitted. So the only way this will work is if it can be guaranteed
> that the line discipline will throttle and later unthrottle us. I
> doubt that is the case, but perhaps Alan can give a more definite
> answer?
If an ldisc throttles it should always later unthrottle. However flow
control is async so at high enough data rates it'll be too slow.
> I would also prefer a more generic solution to the problem so that we
> don't need to re-introduce driver buffering again. Since we already have
> the throttelling mechanism in place, if we could only be notified/find
> out that the tty buffers are say half-full, we could throttle (from
The tty layer actually knows this fact
> within the driver) but still push the remaining buffer still on the wire
> as they arrive. It would of course require a guarantee that such a
> throttle-is-about-to-happen notification is actually followed by (a
> throttle and) unthrottle. Thoughts on that?
tty throttling is at the ldisc layer, the tty buffers are below this. The
space left being 64K - tty->buf.memory_used
So you can certainly add the following routine
int tty_constipated(struct tty *t)
{
if (tty->buf.memory_used > 49152)
return 1;
return 0;
}
EXPORT_SYMBOL_GPL(tty_constipated);
to drivers/tty/tty_buffer.c
The wakeup side is a bit trickier.
The down side of this of course is that you are likely to run at below
peak performance as you'll keep throttling back the hardware, whereas if
you have a tickless kernel with HZ set to 1000 it's probably sufficient
to bump the buffer sizes.
Right now (see tty_buffer.c) it's simply set to 64K as a sanity check
against throttled devices not stopping, but there isn't actually any
reason it couldn't be configurable at port setup time.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
