From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51370) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qp0P5-0002Y4-0s for qemu-devel@nongnu.org; Thu, 04 Aug 2011 12:04:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qp0P4-0003H6-4F for qemu-devel@nongnu.org; Thu, 04 Aug 2011 12:04:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qp0P3-0003Gt-NR for qemu-devel@nongnu.org; Thu, 04 Aug 2011 12:04:10 -0400 Message-ID: <4E3AC2F5.7050805@redhat.com> Date: Thu, 04 Aug 2011 19:04:05 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1312208590-25502-1-git-send-email-aliguori@us.ibm.com> <1312208590-25502-4-git-send-email-aliguori@us.ibm.com> In-Reply-To: <1312208590-25502-4-git-send-email-aliguori@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 03/12] char: introduce tx queue to enable Unix style flow control List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Amit Shah , Hans de Goede , qemu-devel@nongnu.org On 08/01/2011 05:23 PM, Anthony Liguori wrote: > The char layer tries very hard to avoid using an intermediate buffer. The > implication of this is that when the backend does a write(), the data for that > write must be immediately passed to the front end. > > Flow control is needed to handle the likely event that the front end is not > able to handle the data at this point in time. We implement flow control > today by allowing the front ends to register a polling function. The polling > function returns non-zero when it is able to receive data. > > This works okay because most backends are tied to some sort of file descriptor > and our main loop allows polling to be included with file descriptor > registration. > > This falls completely apart when dealing with the front end writing to the > back end though because the front end (devices) don't have an obvious place to > integrate polling. > > Short summary: we're broken by design. A way to fix this is to eliminate > polling entirely and use a Unix style flow control mechanism. This involves > using an intermediate buffer and allowing registration of notifications when > the buffer either has data in it (readability) or is not full (writability). > If you don't have an obvious place to integrate polling, how do you poll for writability? Although, providing a reasonably sized buffer and blocking the vcpu when it's full is a lot better than what we have now. -- error compiling committee.c: too many arguments to function