On Thu, May 19, 2011 at 09:44:35AM +0100, Stefan Hajnoczi wrote:
> On Thu, May 19, 2011 at 8:26 AM, Daniel Veillard <veillard@xxxxxxxxxx> 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.
Actually reading about it at
https://patchwork.kernel.org/patch/43390/
it seems that can be described as
"domain I/O asynchronous handling",
it's a shortcut because it's not for the whole I/O only a part of it
but that in itself is sufficiently generic to be potentially useful
for something else.
I would just suggest to rename the attribute "asyncio" with value
on or off, document the fact that it allows to force on or off some of
the asynchronous I/O handling for the device, and that the default is
left to the discretion of the hypervisor.
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,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list