From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgVWj-0005NH-R0 for qemu-devel@nongnu.org; Sun, 26 May 2013 03:38:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UgVWe-0003MD-8M for qemu-devel@nongnu.org; Sun, 26 May 2013 03:38:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgVWd-0003L5-V5 for qemu-devel@nongnu.org; Sun, 26 May 2013 03:37:56 -0400 Date: Sun, 26 May 2013 10:38:14 +0300 From: "Michael S. Tsirkin" Message-ID: <20130526073814.GB32691@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> <87ip28mmky.fsf@blackfin.pond.sub.org> <20130524161212.GA14700@redhat.com> <519FABD8.7020103@redhat.com> <20130524160042.7b5fc113@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130524160042.7b5fc113@redhat.com> 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: Luiz Capitulino Cc: libvir-list@redhat.com, Markus Armbruster , qemu-devel@nongnu.org, stefanha@redhat.com, Amos Kong , laine@laine.org On Fri, May 24, 2013 at 04:00:42PM -0400, Luiz Capitulino wrote: > On Fri, 24 May 2013 12:05:12 -0600 > Eric Blake wrote: > > > On 05/24/2013 10:12 AM, Michael S. Tsirkin wrote: > > >>>>> > > >>>>> Event message contains the net client name, management might only want > > >>>>> 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 Unix > > >> 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 "give > > >> 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 the > > >> "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 - > > If having the argument is useful for libvirt, then it's fine to have it. > > But I'd be very reluctant to buy any performance argument w/o real > numbers to back them up. Me too. I think it's more convenience than performance. -- MST