From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZ3Jq-0000ZN-Im for qemu-devel@nongnu.org; Sun, 24 Jan 2010 09:20:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZ3Jl-0000X1-Mn for qemu-devel@nongnu.org; Sun, 24 Jan 2010 09:20:02 -0500 Received: from [199.232.76.173] (port=51887 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZ3Jl-0000Wx-Gl for qemu-devel@nongnu.org; Sun, 24 Jan 2010 09:19:57 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:50943) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZ3Jl-0008Bo-GX for qemu-devel@nongnu.org; Sun, 24 Jan 2010 09:19:57 -0500 Received: by yxe26 with SMTP id 26so2239341yxe.4 for ; Sun, 24 Jan 2010 06:19:56 -0800 (PST) Message-ID: <4B5C5709.3050008@codemonkey.ws> Date: Sun, 24 Jan 2010 08:19:53 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 08/11] QMP: Asynchronous messages enable/disable support 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> In-Reply-To: <4B5C5682.40506@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: Avi Kivity Cc: armbru@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, Luiz Capitulino 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. Regards, Anthony Liguori