[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Thu, May 19, 2011 at 8:26 AM, Daniel Veillard <veillard redhat com> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]