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.
Stefan
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list