Re: [Qemu-devel] [PATCH v3 2/2] net: introduce command to query rx-filter information

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, May 24, 2013 at 04:00:42PM -0400, Luiz Capitulino wrote:
> On Fri, 24 May 2013 12:05:12 -0600
> Eric Blake <eblake@redhat.com> 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