From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ufrjf-0007Fr-AA for qemu-devel@nongnu.org; Fri, 24 May 2013 09:08:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfrjY-0007Sz-Vr for qemu-devel@nongnu.org; Fri, 24 May 2013 09:08:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfrjY-0007St-Mf for qemu-devel@nongnu.org; Fri, 24 May 2013 09:08:36 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4OD8aWd022069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 24 May 2013 09:08:36 -0400 Date: Fri, 24 May 2013 09:08:34 -0400 From: Luiz Capitulino Message-ID: <20130524090834.41dd9108@redhat.com> In-Reply-To: <519F6350.1040502@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Eric Blake Cc: Amos Kong , qemu-devel@nongnu.org, stefanha@redhat.com, mst@redhat.com On Fri, 24 May 2013 06:55:44 -0600 Eric Blake wrote: > On 05/24/2013 06:23 AM, Luiz Capitulino wrote: > >>> I don't think we need this argument. This command is quite simple in its > >>> response, let's do this filtering in HMP only. > >> > >> Event message contains the net client name, management might only want > >> to query the single net client. > > > > The client can do the filtering itself. > > If we're arguing that we want this to be as responsive as possible, then > the less data we send over the wire, the faster management can react to > the guest's request for a particular NIC. That is, if libvirt is > listening to events that says NIC2 wants to change rx-filter, libvirt > would rather do a filtered query where it knows the JSON array of 1 > element matches NIC2 data, rather than do a global query and search > through the returned array until it finds NIC2. This sounds like premature optimization to me, but I wonder if instead of cluttering commands with arguments to do the filtering we could add some standard way of doing this in the QAPI. It was you who suggested a filter command? > Filtering is relatively easy to add, whether you do it in QMP or make > every client add it. Libvirt will survive if you don't have filtering, > but I don't see why we can't have it in QMP. Also, if you DO decide to > rip filtering out of QMP, you STILL need to keep a per-NIC flag. Since > the events say which NIC is requesting a change, even if the query reads > all nics, libvirt will only change the macvtap settings of the nic(s) > for which it has received an event (it doesn't make sense to waste time > requesting a (no-op) change to macvtap settings on a nic that hasn't > requested a change). But if you argue that having no filtering in the > QMP command means that you can get away with a single flag instead of a > per-nic flag, then you will fail to emit an event for NIC2 if it changes > in between the time that NIC1 fired an event and libvirt finally does > the query, and libvirt wouldn't realize that NIC2 also needs a macvtap > change. >