From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UczrE-0007H4-OH for qemu-devel@nongnu.org; Thu, 16 May 2013 11:12:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UczrC-0003vf-Ay for qemu-devel@nongnu.org; Thu, 16 May 2013 11:12:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53518) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UczrC-0003vK-3S for qemu-devel@nongnu.org; Thu, 16 May 2013 11:12:38 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4GFCbrD003663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 16 May 2013 11:12:37 -0400 Message-ID: <5194F764.6010809@redhat.com> Date: Thu, 16 May 2013 09:12:36 -0600 From: Eric Blake MIME-Version: 1.0 References: <1368702445-30733-1-git-send-email-akong@redhat.com> <1368702445-30733-2-git-send-email-akong@redhat.com> <20130516121745.GE31841@redhat.com> <5194F41E.3020501@redhat.com> <20130516150326.GB2485@redhat.com> In-Reply-To: <20130516150326.GB2485@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2JARLLCAUISIOMFBNPAOR" 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: "Michael S. Tsirkin" Cc: Amos Kong , qemu-devel@nongnu.org, stefanha@redhat.com, lcapitulino@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2JARLLCAUISIOMFBNPAOR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/16/2013 09:03 AM, Michael S. Tsirkin wrote: > On Thu, May 16, 2013 at 08:58:38AM -0600, Eric Blake wrote: >> On 05/16/2013 06:17 AM, Michael S. Tsirkin wrote: >>> On Thu, May 16, 2013 at 07:07:24PM +0800, Amos Kong wrote: >>>> Introduce this new QMP event to notify management after guest change= s >>>> mac-table configuration. >>>> >>> >>> This makes it easy for guest to flood management with >>> spurious events. >>> How about we set a flag after this, and avoid sending any more >>> events until management queries the filter status? >>> =20 >> >> Or use rate-limiting, similar to what we have done for other >> guest-triggered events (such as BALLOON_CHANGE), where management can >> then tweak the maximum frequency at which it is willing to receive eve= nts. >> >> --=20 >> Eric Blake eblake redhat com +1-919-301-3266 >> Libvirt virtualization library http://libvirt.org >> >=20 > I'm not sure how would management set the rate though, > and any throttling here might hurt the guest, > unlike the balloon. If I understand how memballoon throttling works, throttling is NOT guest-visible; it merely controls how frequently the guest can trigger an event to the host. The host always gets the latest guest status, but only after a timeout has occurred since the last event sent (therefore, 2 back-to-back changes mean that the second event isn't sent until the timeout elapses; 3 back-to-back means that the 2nd is dropped and only the first and third changes get sent, with the 3rd waiting until after the timeout). That is, not all changes reach the host, the first change always happens immediately, but subsequent changes may be deferred until the timeout elapses, but the host will eventually see the final change, and no slower than the frequency it configures for the throttling. Or are you are arguing that if the guest makes a request, but the host waits until a second has elapsed before it even gets the event to act on the request, then the guest has suffered a performance loss? >=20 > OTOH what I proposed kind of moderates itself automatically. Your approach (no more events until the host has acknowleged) has a potential problem if the host misses the event (because of a libvirtd restart, for example - but then again, on a libvirtd restart, libvirt should probably query current state to get itself back in sync); and also means that the host sees stale event data if subsequent events were squelched because the host hasn't reacted to the first event yet. The existing throttling approach ensures that if the event includes latest guest information, then the host doesn't even have to do do a query, and is guaranteed that reacting to the final event will always see the most recent request. But most importantly, if the existing throttling works, why do we have to invent a one-off approach for this event instead of reusing existing code? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2JARLLCAUISIOMFBNPAOR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRlPdkAAoJEKeha0olJ0Nq4SIH/jDgubsp0wXCt4k9Oof9Nbkz VGgfP4MpMTOgVoOXobyKhRC7fBWjjXH3XFw6HaPbjgeOy5gv4wTMFEITD2KIrTeL 0H/yIPDVO1U/FN0zfChRlks9P10i1FgcF3DoM6a8rojk4bv/hX3V95lQ8nkkj/kR pksjJdmT43rNvgUr7XBzgYkD0bTIVdL1uh+9oKXeT7gdxXEcraOtCXfIBKidrmX9 qclp0fPAM7t4PE227PxWH5jSTlv5EnxIc1MKFAadEpOgcEtZ+FL0HCpDV65dRG8Z +rY/z4hmeNvAJnduEeV2/ZpKDKVdbeZa1YD5o4PL2JGP0c7Lx/KH4vpo/b1mTUw= =yANE -----END PGP SIGNATURE----- ------enig2JARLLCAUISIOMFBNPAOR--