On Sun, May 26, 2013 at 10:38:14AM +0300, Michael S. Tsirkin wrote: > 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@xxxxxxxxxx> 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. Agreed. I suggested filtering on a NIC for usability rather than performance reasons. QMP should be easy to use. Requiring every client to fish for the right NIC in a bunch of output that gets discarded is not convenient. Stefan -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list