qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 08/11] QMP: Asynchronous messages enable/disable


From: Luiz Capitulino
Subject: Re: [Qemu-devel] [PATCH 08/11] QMP: Asynchronous messages enable/disable support
Date: Mon, 25 Jan 2010 10:02:06 -0200

On Sun, 24 Jan 2010 08:19:53 -0600
Anthony Liguori <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]