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@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.
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