Re: [PATCH 18/31] virtio: console: Buffer data that comes from the host

[Amit Shah <amit.shah@redhat.com>]

On (Thu) Jan 14 2010 [09:45:12], Rusty Russell wrote:
> On Wed, 13 Jan 2010 09:54:52 pm Amit Shah wrote:
> > On (Wed) Jan 13 2010 [21:43:32], Rusty Russell wrote:
> > > On Wed, 13 Jan 2010 04:41:48 pm Amit Shah wrote:
> > > > On (Mon) Jan 04 2010 [15:17:17], Amit Shah wrote:
> > > > > On (Mon) Jan 04 2010 [19:45:30], Rusty Russell wrote:
> > > > > > On Wed, 23 Dec 2009 01:04:28 am Amit Shah wrote:
> > > > > > > The console could be flooded with data from the host; handle this
> > > > > > > situation by buffering the data.
> > > > > > 
> > > > > > Is this still true?  If we only add_buf when we're ready, surely the host
> > > > > > can't flood us with one virtqueue per port?
> > > > > 
> > > > > I guess I meant something completely different. This message is
> > > > > definitely misleading and I'll re-word it.
> > > > > 
> > > > > You're right; we don't need the 'guest throttling' feature that was
> > > > > needed earlier.
> > > > 
> > > > BTW I meant this series doesn't have the guest throttling feature.
> > > > 
> > > > Rusty, did you just have this comment for the series? If yes, I'll just
> > > > re-send this patch with a fixed description.
> > > 
> > > I don't see why we ever allocate more than one incoming buffer though?
> > 
> > To prevent against a fast host app sending data to a slow guest
> > consumer.
> > 
> > Also, we use the in_vq for the buffering, so the number of buffers is
> > limited by the queue size that's declared by the host.
> 
> But if the guest only ever registers one input buffer at a time, we get the
> same effect.  And it means we use less memory.  And our code is simpler.

The number of buffers to be registered in the vq comes from the host
anyway; if the host wants to be able to use multiple buffers, we should
be able to use them.

Also, we lose out on the ability of the host to send us data when the
guest is slow to read.

(I also see this as a policy decision being made in the guest to limit
to one buffer at a time; the decision should be made by the host: if the
guest is started with a bigger vq by the host, the kernel is capable of
using it all...)

> Similar with output.

For output I've already switched to using one buffer per vq and spinning
till the host acks having received the buffer.

		Amit