From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZNe8-0006JH-LR for qemu-devel@nongnu.org; Mon, 25 Jan 2010 07:02:20 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZNe3-0006G9-Q7 for qemu-devel@nongnu.org; Mon, 25 Jan 2010 07:02:20 -0500 Received: from [199.232.76.173] (port=51525 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZNe3-0006Fz-BR for qemu-devel@nongnu.org; Mon, 25 Jan 2010 07:02:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2624) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZNe2-0000ox-Oj for qemu-devel@nongnu.org; Mon, 25 Jan 2010 07:02:15 -0500 Date: Mon, 25 Jan 2010 10:02:06 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH 08/11] QMP: Asynchronous messages enable/disable support Message-ID: <20100125100206.01b76ce8@doriath> In-Reply-To: <4B5C5709.3050008@codemonkey.ws> References: <1264108180-3666-1-git-send-email-lcapitulino@redhat.com> <1264108180-3666-9-git-send-email-lcapitulino@redhat.com> <4B59E8DF.5020001@codemonkey.ws> <4B5C2251.7050509@redhat.com> <4B5C5358.2000900@codemonkey.ws> <4B5C5682.40506@redhat.com> <4B5C5709.3050008@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: armbru@redhat.com, aliguori@us.ibm.com, Avi Kivity , qemu-devel@nongnu.org On Sun, 24 Jan 2010 08:19:53 -0600 Anthony Liguori wrote: > On 01/24/2010 08:17 AM, Avi Kivity wrote: > > On 01/24/2010 04:04 PM, Anthony Liguori wrote: > >>> I agree with that, but we can look at async messages as a baseline > >>> protocol capability (thus no negotiation required), and the new > >>> command only enabled individual messages. > >> > >> > >> To be honest, I don't think there's really a need to mask individual > >> messages. A client can always ignore messages it doesn't care > >> about. There is no side effect of receiving a message so there is no > >> functional implication of receiving messages you don't care about. > >> > >> The only time it would matter is if we had a really high volume of > >> messages. I'd suggest waiting until a message is introduced that > >> could potentially have a high rate and then implement a mechanism to > >> mask it. For now, it just adds unnecessary complexity. > > > > Fair enough. But then, why can't all clients do that? Dropping an > > async notification is maybe one line of code. > > I agree. The only argument I can imagine for masking is if we had a > really, really high volume event that caused bandwidth issues. I don't > think that's an appropriate use of async messages though so I don't > think this will ever happen. The only real client writer we have thought it would be a good idea to disable them by default. If we don't this now and add a masking command later, then clients that don't want certain messages will have to deal with them between the window of qmp_swicth_mode and masking. I don't have strong opinions here though.