On Thu, May 19, 2011 at 11:24 PM, Eric Blake <eblake@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list