11:12 a.m.
On Fri, May 24, 2013 at 05:20:13PM +0200, Markus Armbruster wrote:
Eric Blake <eblake(a)redhat.com> writes:
> 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.
No disagreement on the need for a per-NIC flag.
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.
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.
We need the query for macvtap devices. We don't need it
for tap devices. In that case you don't want tap device info.
Maybe some libvirt guys can tell us whether they prefer
a per device query or a global one with info for all NICs?
I think for HMP it's best to have nic optional.
Is it a good idea to make QMP match HMP closely?
--
MST
1:05 p.m.
New subject: [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 - that is, the rx-filter query will probably
always be invoked in response to an event, at which point libvirt only
cares about the filter status of the nic named in the event. And
ultimately libvirt knows what nics it passed to the guest, so even if
there isn't a global query and I guessed wrong about libvirt never
wanting all state at once, it would still be possible for libvirt to
iterate over one query per nic. On the other hand, consistency with
other query-* QMP commands says that most of them return as much
information as possible all the time, and generally libvirt likes this -
even the newly-added query-command-line-options has a filtering option,
but current libvirt.git only uses it once in global mode rather than
once-per-option in filtered mode.
We need the query for macvtap devices. We don't need it
for tap devices. In that case you don't want tap device info.
Maybe some libvirt guys can tell us whether they prefer
a per device query or a global one with info for all NICs?
Libvirt can cope either way. I personally like the idea of allowing
both global and filtered queries, without second-guessing what
management apps will prefer to use, and don't think filtering adds that
much complexity. But if you want to insist on avoiding filtering, I'd
rather have a global query than a mandatory name argument, for
consistency with other query-* commands, even if libvirt then ends up
doing its own filtering.
If we get introspection into qemu 1.6 at the same time as the new query
for rx-filters, it really won't matter whether you start with
global-only or mandatory name-only; either way, if we change our mind
and add the other mode in qemu 1.7, libvirt will still be able to use
introspection to determine whether the argument is present in one
direction (going from global-only to optional filtering), or whether the
argument has been made optionl in the other direction (going from
mandatory name to optional global).
I think for HMP it's best to have nic optional.
This is true, no matter what we decide for QMP.
Is it a good idea to make QMP match HMP closely?
QMP has to provide enough information for HMP to do its job. How will
HMP do global listing if QMP doesn't provide a way to get all the
devices at once? Remember, libvirt knows what devices it told qemu to
create, but I don't know that HMP has the same visibility into the list
of possible devices that can be queried. So you may need a global mode
to begin with.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
3 p.m.
New subject: [libvirt] [Qemu-devel] [PATCH v3 2/2] net: introduce command to query rx-filter information
On Fri, 24 May 2013 12:05:12 -0600
Eric Blake <eblake(a)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.
2:38 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH v3 2/2] net: introduce command to query rx-filter information
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(a)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
3:36 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH v3 2/2] net: introduce command to query rx-filter information
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(a)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
4198
days inactive
4201
days old
4 comments
4 participants
participants (4)
-
Eric Blake -
Luiz Capitulino -
Michael S. Tsirkin -
Stefan Hajnoczi