From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUUd3-0002YG-4b for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:29:01 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUUcy-0002Wa-80 for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:29:00 -0500 Received: from [199.232.76.173] (port=59407 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUUcy-0002WX-1n for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:28:56 -0500 Received: from mail-qy0-f189.google.com ([209.85.221.189]:37690) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUUcx-0007Ng-NN for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:28:55 -0500 Received: by qyk27 with SMTP id 27so9707226qyk.20 for ; Mon, 11 Jan 2010 16:28:55 -0800 (PST) Message-ID: <4B4BC244.7030508@codemonkey.ws> Date: Mon, 11 Jan 2010 18:28:52 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 5/8] virtio-serial-bus: Add support for buffering guest output, throttling guests References: <1262849506-27132-6-git-send-email-amit.shah@redhat.com> <20100108011231.GA5011@shareable.org> <20100108050351.GB8999@amit-x200.redhat.com> <20100108133503.GA19328@shareable.org> <4B475CD3.4080604@codemonkey.ws> <20100111083904.GB6061@amit-x200.redhat.com> In-Reply-To: <20100111083904.GB6061@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/11/2010 02:39 AM, Amit Shah wrote: > On (Fri) Jan 08 2010 [10:26:59], Anthony Liguori wrote: > >> On 01/08/2010 07:35 AM, Jamie Lokier wrote: >> >>> Sometimes it looks like TCP is maintaining write boundaries, but it is >>> just an artifact of its behaviour on many systems, and is not reliable >>> even on those systems where it seems to happen most of the time. Even >>> when connecting to localhost, you cannot rely on that. I have seen >>> people write code assuming TCP keeps boundaries, and then some weeks >>> later they are very confused debugging their code because it is not >>> reliable... >>> >>> Since VNC is clearly designed to work over TCP, and is written by >>> people who know this, I'm wondering why you think it needs to be >>> different for virtio-serial. >>> >>> >> I'm confused about why the buffering is needed in the first place. >> >> I would think that any buffering should be pushed back to the guest. >> IOW, if there's available data from the char driver, but the guest >> doesn't have a buffer. Don't select on the char driver until the guest >> has a buffer available. If the guest attempts to write data but the >> char driver isn't ready to receive data, don't complete the request >> until the char driver can accept data. >> > This is a different thing from what Jamie's talking about. A guest or a > host might be interested in communicating data without waiting for the > other end to come up. The other end can just start consuming the data > (even the data that it missed while it wasn't connected) once it's up. > > (I can remove this option for now and add it later, if you prefer it > that way.) > If it's not needed by your use case, please remove it. Doing buffering gets tricky because you can't allow an infinite buffer for security reasons. All you end up doing is increasing the size of the buffer beyond what the guest and client are capable of doing. Since you still can lose data, apps have to be written to handle this. I think it adds complexity without a lot of benefit. Regards, Anthony Liguori > Amit >