From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgxPh-0006KJ-Db for qemu-devel@nongnu.org; Mon, 27 May 2013 09:24:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UgxPb-0006nM-V2 for qemu-devel@nongnu.org; Mon, 27 May 2013 09:24:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42961) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgxPb-0006nH-Mw for qemu-devel@nongnu.org; Mon, 27 May 2013 09:24:31 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4RDOUBM012275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 27 May 2013 09:24:30 -0400 Date: Mon, 27 May 2013 09:24:28 -0400 From: Luiz Capitulino Message-ID: <20130527092428.0ce3581d@redhat.com> In-Reply-To: <20130527091011.1a8bf205@redhat.com> References: <20130516121745.GE31841@redhat.com> <5194F41E.3020501@redhat.com> <20130516150326.GB2485@redhat.com> <5194F764.6010809@redhat.com> <20130516151723.GA2726@redhat.com> <20130523115403.4d5f587a@redhat.com> <20130523171834.GA31349@redhat.com> <20130523132633.388ee1c5@redhat.com> <20130524121016.GC8669@redhat.com> <20130524085136.4e13ab49@redhat.com> <20130527093425.GC6120@t430s.nay.redhat.com> <20130527091011.1a8bf205@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/2] net: introduce MAC_TABLE_CHANGED event List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Amos Kong , qemu-devel@nongnu.org, stefanha@redhat.com, "Michael S. Tsirkin" On Mon, 27 May 2013 09:10:11 -0400 Luiz Capitulino wrote: > > We use the QMP event to notify management about the mac changing. > > > > In this thread, we _wrongly_ considered to use qmp approach to delay > > the event for avoiding the flooding. > > > > eg: monitor_protocol_event_throttle(NIC_RX_FILTER_CHANGED, 1000); > > > > Now we have a solution (using a flag to turn on/off the notify) to avoid the > > flooding, only emit the event if we have no un-read event. > > > > If we want to (flag is on) emit the event, we wish the event be sent ASAP > > (so event_throttle isn't needed). > > Unfortunately this doesn't answer my question. I did understand why you're > not using the event throttle API (which is because you don't want to slow down > the guest, not the QMP client). > > My point is whether coupling the event with the query command is really > justified or even if it really fixes the problem. Two points: > > 1. Coupling them is bad design, and will probably strike back, as we plan > for a better API for events where events can be disabled I meant we may in the future, for example, introduce the ability to disable commands (and events). One could argue that the event w/o a query command is not that useful, as events can be lost. But loosing an event is one thing, not having it because it got disabled by a side effect is another. But anyway, my main point in this thread is to make sure we at least justify having this coupling. Aren't we optimizing prematurely? Aren't we optimizing for a corner case? That's what I want to see answered.