From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34895) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfwMp-00022Q-Ks for qemu-devel@nongnu.org; Fri, 24 May 2013 14:05:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfwMf-0007C1-F0 for qemu-devel@nongnu.org; Fri, 24 May 2013 14:05:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfwMf-0007Bn-7P for qemu-devel@nongnu.org; Fri, 24 May 2013 14:05:17 -0400 Message-ID: <519FABD8.7020103@redhat.com> Date: Fri, 24 May 2013 12:05:12 -0600 From: Eric Blake MIME-Version: 1.0 References: <1369300080-31377-1-git-send-email-akong@redhat.com> <1369300080-31377-3-git-send-email-akong@redhat.com> <20130523120325.3113c687@redhat.com> <20130524030813.GB1550@t430s.nay.redhat.com> <20130524082326.452cc9f0@redhat.com> <519F6350.1040502@redhat.com> <87ip28mmky.fsf@blackfin.pond.sub.org> <20130524161212.GA14700@redhat.com> In-Reply-To: <20130524161212.GA14700@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2DRFERCSUFBIXWPBXRDIB" Subject: Re: [Qemu-devel] [PATCH v3 2/2] net: introduce command to query rx-filter information List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: libvir-list@redhat.com, qemu-devel@nongnu.org, Markus Armbruster , stefanha@redhat.com, Luiz Capitulino , Amos Kong , laine@laine.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2DRFERCSUFBIXWPBXRDIB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/24/2013 10:12 AM, Michael S. Tsirkin wrote: >>>>> >>>>> Event message contains the net client name, management might only w= ant >>>>> to query the single net client. >>>> >>>> The client can do the filtering itself. >>> >> I'm not sure I buy the responsiveness argument. Sure, the fastest I/O= >> is no I/O, but whether you read and parse 100 bytes or 1000 from a Uni= x >> domain socket once in a great while shouldn't make a difference. And the time spent malloc'ing the larger message to send from qemu, as well as the time spent malloc'ing the libvirt side that parses the qemu string into C code for use, and the time spent strcmp'ing every entry to find the right one... It really IS more efficient to filter as low down in the stack as possible, once it is determined that filtering is desirable. Whether filtering makes a difference in performance is a different question - you may be right that always returning the entire list and making libvirt do its own filtering will still not add any more noticeable delay compared to libvirt doing a filtered query, if the bottleneck lies elsewhere (such as libvirt telling macvtap its new configration). >> >> My main concern is to keep the external interface simple. I'm rather >> reluctant to have query commands grow options. >> >> In a case where we need the "give me everything" query anyway, the "gi= ve >> me this particular part" option is additional complexity. Needs >> justification, say arguments involving throughput, latency or client >> complexity. >> >> Perhaps cases exist where we never want to ask for everything. Then t= he >> "give me everything" query is useless, and the option should be >> mandatory. For this _particular_ interface, I'm not sure whether libvirt will ever use an unfiltered query - that is, the rx-filter query will probably always be invoked in response to an event, at which point libvirt only cares about the filter status of the nic named in the event. And ultimately libvirt knows what nics it passed to the guest, so even if there isn't a global query and I guessed wrong about libvirt never wanting all state at once, it would still be possible for libvirt to iterate over one query per nic. On the other hand, consistency with other query-* QMP commands says that most of them return as much information as possible all the time, and generally libvirt likes this - even the newly-added query-command-line-options has a filtering option, but current libvirt.git only uses it once in global mode rather than once-per-option in filtered mode. >=20 > We need the query for macvtap devices. We don't need it > for tap devices. In that case you don't want tap device info. >=20 > Maybe some libvirt guys can tell us whether they prefer > a per device query or a global one with info for all NICs? Libvirt can cope either way. I personally like the idea of allowing both global and filtered queries, without second-guessing what management apps will prefer to use, and don't think filtering adds that much complexity. But if you want to insist on avoiding filtering, I'd rather have a global query than a mandatory name argument, for consistency with other query-* commands, even if libvirt then ends up doing its own filtering. If we get introspection into qemu 1.6 at the same time as the new query for rx-filters, it really won't matter whether you start with global-only or mandatory name-only; either way, if we change our mind and add the other mode in qemu 1.7, libvirt will still be able to use introspection to determine whether the argument is present in one direction (going from global-only to optional filtering), or whether the argument has been made optionl in the other direction (going from mandatory name to optional global). > I think for HMP it's best to have nic optional. This is true, no matter what we decide for QMP. > Is it a good idea to make QMP match HMP closely? QMP has to provide enough information for HMP to do its job. How will HMP do global listing if QMP doesn't provide a way to get all the devices at once? Remember, libvirt knows what devices it told qemu to create, but I don't know that HMP has the same visibility into the list of possible devices that can be queried. So you may need a global mode to begin with. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2DRFERCSUFBIXWPBXRDIB 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/ iQEcBAEBCAAGBQJRn6vYAAoJEKeha0olJ0NqrOEH/jmMjw21mXQM9lF3SCnAyMeU zJJeT0SiHsK74YMJRNefUNPUlt6VFDmzQ0t1HFpUENxCzwS9mHgdji6uo63yqAcM vPxjNXmccm2Qqzt0c0TDfzVVGfrLI9O4KEhDViCicCXEFSVvXpbPGTf9EbH1loMr DBV+N1aJnP4unXrf5O1aIzHZibVUpZ9D7uZDxR17cr1tBhWLt1ZG1Ll6OKtVrUVd N9Rdlli5wIMyvwm//GQQZhNmGK94yTpXfXhwo7EfWWp8/Y/VQ2Tyzc1a4PCLwVnU cVYMuIFWw0Yho6o/MvbTjw6MKlxxc1sAg/W5x6ZTd/bcsY6GMvo6w+xW/EO7cno= =u/3g -----END PGP SIGNATURE----- ------enig2DRFERCSUFBIXWPBXRDIB--