From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NVRje-0003Kf-Nd for qemu-devel@nongnu.org; Thu, 14 Jan 2010 10:35:46 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NVRjZ-0003Hi-VX for qemu-devel@nongnu.org; Thu, 14 Jan 2010 10:35:46 -0500 Received: from [199.232.76.173] (port=50705 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NVRjZ-0003Hb-IR for qemu-devel@nongnu.org; Thu, 14 Jan 2010 10:35:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:65070) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NVRjZ-0001uo-34 for qemu-devel@nongnu.org; Thu, 14 Jan 2010 10:35:41 -0500 Date: Thu, 14 Jan 2010 21:04:25 +0530 From: Amit Shah Subject: Re: [Qemu-devel] [PATCH 0/8] virtio-console: Move to qdev, multiple devices, generic ports Message-ID: <20100114153425.GG27104@amit-x200.redhat.com> References: <1263475063-15238-1-git-send-email-amit.shah@redhat.com> <4B4F2B82.9000800@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4F2B82.9000800@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org 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