On Fri, Feb 22, 2013 at 09:53:11AM +0100, Paolo Bonzini wrote:
> Il 22/02/2013 00:38, mdroth ha scritto:
> > On Thu, Feb 21, 2013 at 11:12:01PM +0100, Paolo Bonzini wrote:
> >> Il 21/02/2013 22:07, mdroth ha scritto:
> >>>>>
> >>>>> 100% agree. In particular hw/dataplane/event-poll.c should be the first
> >>>>> to go away, but AioContext provides the functionality that Ping Fan
> >>>>> needs. But hw/dataplane/vring.c will probably be here for a longer
> >>> Has there been any discussion around introducing something similar to
> >>> AioContexts for fd handlers? This would avoid the dataplane-specific hooks
> >>> needed for NetClients in this series.
> >>
> >> AioContext can include file descriptors on POSIX systems (used for NBD
> >> and other network backends), see aio_set_fd_handler.
> >
> > Sorry, was using "fd handlers" too generally. I mean specifically for
> > the qemu_set_fd_handler interfaces, where we currently rely on a single list
> > of IOHandlerRecords for registration and a single loop to drive them. Would
> > be nice if we could drive subsets of those via mini main loops, similar to
> > the
> > way dataplane threads would with a particular AioContext via aio_poll (or
> > perhaps
> > the exact same way)
>
> Yes, that's what I meant actually. You can already do it for POSIX,
> unfortunately Windows poses extra complication because sockets are not
> handles.
>
> Moving more of the os_host_main_loop_wait to AioContext would be
> possible (timers are on the todo list, in fact), but we should only do
> it as need arises.
Were you planning on hanging another GSource off of AioContext to handle
timers?
I wonder if adding an interface to AioContext that allows you to just
register an arbitrary GSource might be the right approach.
We could consolidate qemu_set_fd_handler()/qemu_aio_set_fd_handler() on
POSIX by teaching the current GSource about fd_read_poll functions, and on
Windows qemu_set_fd_handler() would tie into a winsock-specific GSource
that we register with an AioContext. Might be able to do similar with
GSources for slirp and the qemu_add_wait_object() stuff.
Or maybe that's the plan already... glib-style main loops, but not
intrinsically tethered to GMainContext so we can implement our own
locking/priority/loop constructs if need be... seems to be what's been
discussed elsewhere, just trying to get an idea of what that might look
like.
> possible (timers are on the todo list, in fact), but we should only do
> it as need arises.
Yup, don't mean to get ahead of things, my main interest is just in how
we might deal with the interaction between NetClients and virtio-net
dataplane threads without introducing ad-hoc, dataplane-specific
mechanisms. If there was a general way for Nic to tell it's NetClient
peer "hey, i have my own thread/main loop, here's my {Aio,*}Context, register
your handlers there instead" I think this series might look a lot more
realistic as a default, or at least make merging it less risky. But the
right way to do that seems to tie into the discussion around making
other aio sources more GMainContext/AioContext-ish.
>
> Paolo
>
> > Currently, Ping Fan's patches basically do this already by accessing a
> > global reference to the vnet worker thread and attaching events/handlers to
> > it's event loop via a new set of registration functions (PATCH 7).
> >
> > I think generalizing this by basing qemu_set_fd_handler() around
> > AioContext, or something similar, would help to extend support to other
> > NetClient implementations without requiring dataplane-specific hooks
> > throughout.
>
