From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NXF9c-00031p-3H for qemu-devel@nongnu.org; Tue, 19 Jan 2010 09:34:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NXF9W-00031C-Bn for qemu-devel@nongnu.org; Tue, 19 Jan 2010 09:33:58 -0500 Received: from [199.232.76.173] (port=49149 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NXF9W-000319-4w for qemu-devel@nongnu.org; Tue, 19 Jan 2010 09:33:54 -0500 Received: from qw-out-1920.google.com ([74.125.92.146]:56902) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NXF9V-00029K-Ri for qemu-devel@nongnu.org; Tue, 19 Jan 2010 09:33:54 -0500 Received: by qw-out-1920.google.com with SMTP id 5so275569qwf.4 for ; Tue, 19 Jan 2010 06:33:52 -0800 (PST) Message-ID: <4B55C2CC.3050705@codemonkey.ws> Date: Tue, 19 Jan 2010 08:33:48 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/8] virtio-console: Move to qdev, multiple devices, generic ports References: <1263475063-15238-1-git-send-email-amit.shah@redhat.com> <4B4F2B82.9000800@codemonkey.ws> <20100114153425.GG27104@amit-x200.redhat.com> In-Reply-To: <20100114153425.GG27104@amit-x200.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: qemu-devel@nongnu.org On 01/14/2010 09:34 AM, Amit Shah wrote: > 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.) > The guest already gets an ack when data is consumed. The host adds the consumed buffer to the used ring. > 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. > The rings themselves are buffers. Since each port has a ring, each port has independent buffering right now. Regards, Anthony Liguori