qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/8] virtio-console: Move to qdev, multiple devi


From: Amit Shah
Subject: Re: [Qemu-devel] [PATCH 0/8] virtio-console: Move to qdev, multiple devices, generic ports
Date: Thu, 14 Jan 2010 21:04:25 +0530
User-agent: Mutt/1.5.19 (2009-01-05)

On (Thu) Jan 14 2010 [08:34:42], Anthony Liguori wrote:
> On 01/14/2010 07:17 AM, Amit Shah wrote:
>> Hello people,
>>
>> This iteration of the series removes the START and END flags (and
>> hence the header associated with each buffer). That's the major change
>> since the last submission.
>>    
>
> I think the biggest issue remaining is the buffering.
>
> I think this is a pretty fundamental issue to work out since it  
> determines the very nature of the transport (stream vs. datagram).

The buffering is done so that the guest copy of the buffer is acked so
that the guest can go about doing other things. (Currently the guest
spins till a buffer is acked by the host and waiting for individual
ports to flush their data to whichever receiver will consume some time.)

This also puts buffer management in one place: not all ports will
consume all the data given to them. There's a need to maintain the
buffer contents till the ports consume all the data. This buffer
management can either be done by the individual ports, or it could be
done by the bus code. I prefer doing it in the bus code since the code
will be the same and be in one place instead of each port doing it
separately all around the place.

> Because you have to put a max buffer size on the transport, I think  
> buffering is a really flawed approach provably equivalent to just  
> increasing the message size within the transport.  In general, the later  
> is a better approach because then the guest is using it's memory vs.  
> using host memory.

OK; alternative solutions on how to handle this?

                Amit




reply via email to

[Prev in Thread] Current Thread [Next in Thread]