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

On Thu, May 19, 2011 at 8:26 AM, Daniel Veillard <veillard(a)redhat.com&gt; wrote: > On Wed, May 18, 2011 at 04:07:30PM +0800, Daniel Veillard wrote: >> On Tue, May 17, 2011 at 03:56:11PM +0100, Daniel P. Berrange wrote: >> > On Tue, May 17, 2011 at 04:49:17PM +0200, Michal Privoznik wrote: >> > > This feature allows QEMU to achieve higher throughput, but is available >> > > only in recent versions. It is accessible via ioeventfd attribute >> > > with accepting values 'on', 'off'. Only experienced users needs to set >> > > this, because QEMU defaults to 'on', meaning higher performance. >> > > Translates into virtio-{blk|net}-pci.ioeventfd option. >> [...] >> > > +          <li> >> > > +           The optional <code>ioeventfd</code> attribute enables or disables >> > > +           IOEventFD feature for virtqueue notify. The value can be either >> > > +           'on' or 'off'. >> > > +            <span class="since">Since 0.9.2 (QEMU and KVM only)</span> >> > >> > This is a qemu specific attribute name & description. IMHO we shouldn't >> > be exposing that directly. Who even knows what effect it actually has >> > on the guests... >> >>   Agreed, what is the semantic of this flag, beside allowing to switch >> something in qemu ? > >  Just to clarify my answer a bit, the problem here is that the patch > does not explain what the ioeventfd qemu flag does in practice and how > it influence the virtualization. To be able to provide a good API and > maintain it long term we need to be able to explain the semantic of > the API (be it a function of the library or part of the XML being used), > only then we can guarantee that there is no misunderstanding about what > it does, and also allow us to reuse it in case the same functionality > is provided by another hypervisor. >  So instead of explaining the option using terms from QEmu, let's > explain what it does in general terms and use those general terms to > model the API, I don't think there is a general API here, ioeventfd is specific to QEMU's architecture. It allows you to switch between two internal threading models for handling I/O emulation. It could change in the future if QEMU's architecture changes. This is not an end-user feature, it's more an internal performance tunable.