Re: [Qemu-devel] [RFC 0/9] QContext: QOM class to support multiple event loops

[mdroth]

On Mon, May 06, 2013 at 07:25:24AM -0500, Anthony Liguori wrote:
> Paolo Bonzini <address@hidden> writes:
> 
> > Il 03/05/2013 18:03, Michael Roth ha scritto:
> >> These patches apply on top of qemu.git master, and can also be obtained 
> >> from:
> >> git://github.com/mdroth/qemu.git qcontext
> >> 
> >> OVERVIEW
> >> 
> >> This series introduces a set of QOM classes/interfaces for event
> >> registration/handling: QContext and QSource, which are based closely on
> >> their GMainContext/GSource GLib counterparts.
> >> 
> >> QContexts can be created via the command-line via -object, and can also be
> >> intructed (via -object params/properties) to automatically start a
> >> thread/event-loop to handle QSources we attach to them.
> >
> > This is an awesome idea.
> 
> Ack.
> 
> > However, it seems a bit overengineered.
> 
> Ack.
> 
> >  Why do we need QSource at all?
> >  In my opinion, we should first change dataplane to use AioContext as a
> > GSource, and benchmark it thoroughly.  If it is fast enough, we can
> > "just" introduce a glib-based QContext and be done with it.  Hopefully
> > that is the case...
> 
> Why even bother with QContext then?

The QContext/GlibQContext object in general, or the QContext base class?

In the case of the former, I think a wrapper around GLib that we can
instantiate from the command-line line and query properties like TIDs
from is necessary for robust control over event loops and CPU resources.
We get this essentially for free with QOM, so I think it makes sense to
use it.

In the case of the latter I'm not too sure. Without the QSource
abstraction there isn't much reason not to use the native GLib
interfaces on the underlying GSources/GMainContexts directly. In which
case GlibQContext would only need to be a container of sorts with some
minor additions like spawning an event thread for itself.

If we ever did need to switch it out in favor of a non-GLib
implementation, it should be a mostly mechanical conversion of
GSource->QSource and adding some wrappers around
g_main_context_prepare/check/etc.

Also along that line, if we're taking the approach of not adding
infrastructure/cruft until we actually have a plan to use it, it probably
makes sense to make QContext a concrete class implemented via GLib, and we
can move the GLib stuff to a sub-class later if we ever end up with another
QContext implementation.

Does this seem reasonable?

> 
> Regards,
> 
> Anthony Liguori
> 
> >
> > Paolo
>