From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUat2-0005s2-NP for qemu-devel@nongnu.org; Tue, 12 Jan 2010 02:09:56 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUasy-0005pS-PX for qemu-devel@nongnu.org; Tue, 12 Jan 2010 02:09:56 -0500 Received: from [199.232.76.173] (port=51182 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUasy-0005pA-Fn for qemu-devel@nongnu.org; Tue, 12 Jan 2010 02:09:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52363) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUasx-0000BD-RJ for qemu-devel@nongnu.org; Tue, 12 Jan 2010 02:09:52 -0500 Date: Tue, 12 Jan 2010 12:38:41 +0530 From: Amit Shah Subject: Re: [Qemu-devel] [PATCH 5/8] virtio-serial-bus: Add support for buffering guest output, throttling guests Message-ID: <20100112070841.GA19438@amit-x200.redhat.com> 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> <4B4BC244.7030508@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4BC244.7030508@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 (Mon) Jan 11 2010 [18:28:52], Anthony Liguori wrote: >>> >>> 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. The buffering has to remain anyway since we can't assume that the ports will consume the entire buffers we pass on to them. So we'll have to buffer the data till the entire buffer is consumed. That, or the buffer management should be passed off to individual ports. Which might result in a lot of code duplication since we can have a lot of these ports in different places in the qemu code. So I guess it's better to leave the buffer management in the bus itself. Which means we get the 'cache_buffers' functionality essentially for free. Amit