[libvirt] [PATCH v2] qemu: Add option to enable/disable IOEventFD feature

[Stefan Hajnoczi]

On Thu, May 19, 2011 at 11:24 PM, Eric Blake <eblake at redhat.com> wrote:
> On 05/19/2011 04:09 PM, Stefan Hajnoczi wrote:
>>>  In case we need to refine later, we can still provide a larger set of
>>> accepted values for that attribute, assuming people really want to
>>> make more distinctive tuning,
>>
>> Inventing a different name makes life harder for everyone.  There is a
>> need for a generic API/notation that covers all virtualization
>> software but this is a hypervisor-specific performance tunable that
>> does not benefit from abstraction.
>
> That's true if we narrow-mindedly think that qemu will be the _only_
> hypervisor that will ever use this feature.  But libvirt has the stated
> goal of accommodating multiple hypervisors, so we'd rather go with the
> generic name even if it requires more mapping.

That approach is an extreme approach, I'm not suggesting to make
everything hypervisor-specific, I'm asking for a practical middle
ground - abstract what is common, leave what is not.

There are many common concepts: how much RAM should the VM have, what
CPU topology, network cards, storage devices.  Those should be
abstracted because they are genuinely common concepts.  However, for
hypervisor-specific features inventing names does no good.  The
feature is not relevant on other hypervisors and abstracting it
removes its semantics.  It becomes purely an exercise in obfuscation.

When I browse the Python documentation many modules are
platform-independent and can be used everywhere.  Some functions or
modules are specifically marked as platform-dependent (and the version
they were introduced in):

"os.initgroups(username, gid)
Call the system initgroups() to initialize the group access list with
all of the groups of which the specified username is a member, plus
the specified group id.

Availability: Unix.

New in version 2.7."

Doing the same in libvirt allows common concepts to be abstracted
while exposing unique ones in a clearly documented way.

>> When I ask a user to try disabling ioeventfd I need to first search
>> through libvirt documentation and/or source code to reverse-engineer
>> this artificial mapping.  This creates an extra source of errors for
>> people who are trying to configure or troubleshoot their systems.  The
>> "I know what the hypervisor-specific setting is but have no idea how
>> to express it in libvirt domain XML" problem is really common and
>> creates a gap between the hypervisor and libvirt communities.
>
> Yes, good documentation that mentions the specific qemu option it maps
> to would be helpful.
>
> Also, libvirt has the domxml-from-native command, and if we do this
> correctly, then you should be able to pass an arbitrary qemu command
> line to libvirt, and ask what the corresponding xml would be.  That
> would make your reverse mapping less difficult.

Thanks for mentioning this command, I'll try it next time.

>>
>> The next time an optimization is added to QEMU you'll have to pick a
>> new name, "asyncio" (already overloaded terminology today) won't be
>> available anymore.  We're going to end up with increasingly contrived
>> or off-base naming.
>
> Then please help us, by suggesting a generic name more suited to this
> particular qemu tuning, but which can still be used for other
> hypervisors if they can also tune the same semantics.

As I've said, inventing generic names only serves to confuse when the
concept is hypervisor-specific and not a common feature.

>>
>> Regarding semantics:
>>
>> Ioeventfd decouples vcpu execution from I/O emulation, allowing the VM
>> to execute guest code while a separate thread handles I/O.  This
>> results in reduced steal time and lowers spinlock contention inside
>> the guest.  Typically guests that are experiencing high system cpu
>> utilization during I/O will benefit from ioeventfd.  On an
>> overcommitted host it could increase guest I/O latency though.  The
>> ioeventfd option is currently only supported on virtio-blk (default:
>> on) and virtio-net (default: off) devices.
>>
>> Please call it ioeventfd.  Also, it can always be toggled using the
>> <qemu:commandline> tag if you don't want to expose it natively in
>> domain XML.
>
> However, use of <qemu:commandline> results in an unsupported
> configuration; we need to expose it natively in domain XML under some
> name or another.
>
> We already have the XML attribute io="threads|native" in the same
> <driver> element, for selecting whether to use the aio flag for a given
> disk driver, so this would not be the first case of selecting a
> different name in the XML.

Just because it has been done before doesn't mean it is a good idea.

Stefan