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

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 -