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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]

On 05/24/2013 06:23 AM, Luiz Capitulino wrote:
>>> I don't think we need this argument. This command is quite simple in its
>>> response, let's do this filtering in HMP only.
>>
>> Event message contains the net client name, management might only want
>> to query the single net client.
> 
> The client can do the filtering itself.

If we're arguing that we want this to be as responsive as possible, then
the less data we send over the wire, the faster management can react to
the guest's request for a particular NIC.  That is, if libvirt is
listening to events that says NIC2 wants to change rx-filter, libvirt
would rather do a filtered query where it knows the JSON array of 1
element matches NIC2 data, rather than do a global query and search
through the returned array until it finds NIC2.

Filtering is relatively easy to add, whether you do it in QMP or make
every client add it.  Libvirt will survive if you don't have filtering,
but I don't see why we can't have it in QMP.  Also, if you DO decide to
rip filtering out of QMP, you STILL need to keep a per-NIC flag.  Since
the events say which NIC is requesting a change, even if the query reads
all nics, libvirt will only change the macvtap settings of the nic(s)
for which it has received an event (it doesn't make sense to waste time
requesting a (no-op) change to macvtap settings on a nic that hasn't
requested a change).  But if you argue that having no filtering in the
QMP command means that you can get away with a single flag instead of a
per-nic flag, then you will fail to emit an event for NIC2 if it changes
in between the time that NIC1 fired an event and libvirt finally does
the query, and libvirt wouldn't realize that NIC2 also needs a macvtap
change.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]