From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qnv7E-0004hX-7Y for qemu-devel@nongnu.org; Mon, 01 Aug 2011 12:13:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qnv7D-0005Jc-Ai for qemu-devel@nongnu.org; Mon, 01 Aug 2011 12:13:16 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:42981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qnv7D-0005JR-6t for qemu-devel@nongnu.org; Mon, 01 Aug 2011 12:13:15 -0400 Received: by ywb3 with SMTP id 3so946745ywb.4 for ; Mon, 01 Aug 2011 09:13:14 -0700 (PDT) Message-ID: <4E36D098.8060706@codemonkey.ws> Date: Mon, 01 Aug 2011 11:13:12 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1312208590-25502-1-git-send-email-aliguori@us.ibm.com> <20110801160410.GF2574@bow.tlv.redhat.com> In-Reply-To: <20110801160410.GF2574@bow.tlv.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/12][RFC] char: add flow control and fix guest_[open|close] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Amit Shah , Hans de Goede On 08/01/2011 11:04 AM, Alon Levy wrote: > On Mon, Aug 01, 2011 at 09:22:58AM -0500, Anthony Liguori wrote: >> The char layer has been growing some nasty warts for some time now as we ask it >> to do things it was never intended on doing. It's been long over due for an >> overhaul and its become evident to me that we need to address this first before >> adding any more features to the char layer. >> >> This series is the start at sanitizing the char layer. It effectively turns >> the char layer into an internal pipe. It supports flow control using an >> intermediate ring queue for each direction. >> >> This series is an RFC because I don't think we should merge the series until we >> completely convert the old style flow control users to the new style. >> >> One particularly nasty area is the mux device. I'm not entirely sure yet how >> to preceed there. >> >> > > So, adding a copy - is that really a good idea? Yes, otherwise I wouldn't have proposed it ;-) > I don't have any alternative code, > so I'm already starting bad, I know, and I understand the want to have a "middle > ground" to ease the logic. You need an intermediate buffer if you want to preserve a simple read/write interface. > Maybe keeping an iovec? add a function on each side for > freeing, i.e. release_be_buffer, release_fe_buffer. At least it could make this as > fast as the current code. I'm thinking of copy/paste for vdagent, usbredir, guest > agent doing dmesg or anything larger. I think you're prematurely optimizing. I think you'll find that there are many other bottlenecks well before this copy becomes an issue. Regardless, correctness needs to trump performance here. We ought to focus on making the layer lossless and sane first, and then we can work on improving performance. Regards, Anthony Liguori > >