From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFktN-000053-IT for qemu-devel@nongnu.org; Wed, 13 Mar 2013 08:34:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFktJ-00017A-Q0 for qemu-devel@nongnu.org; Wed, 13 Mar 2013 08:34:49 -0400 Received: from mail-pb0-f54.google.com ([209.85.160.54]:53092) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFktJ-00014W-Jb for qemu-devel@nongnu.org; Wed, 13 Mar 2013 08:34:45 -0400 Received: by mail-pb0-f54.google.com with SMTP id rr4so975010pbb.27 for ; Wed, 13 Mar 2013 05:34:44 -0700 (PDT) From: Anthony Liguori In-Reply-To: <51405BEA.6080109@redhat.com> References: <1363154346-14827-1-git-send-email-qemulist@gmail.com> <51405BEA.6080109@redhat.com> Date: Wed, 13 Mar 2013 07:34:38 -0500 Message-ID: <87hakfiild.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [RFC PATCH 0/2] port network layer onto glib List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Liu Ping Fan Cc: mdroth , Stefan Hajnoczi , qemu-devel@nongnu.org, "Michael S. Tsirkin" Paolo Bonzini writes: > Il 13/03/2013 06:59, Liu Ping Fan ha scritto: >> These series aim to port network backend onto glib, and >> prepare for moving towards making network layer mutlit-thread. >> The brief of the whole aim and plan is documented on >> http://wiki.qemu.org/Features/network_reentrant >> >> In these series, attach each NetClientState with a GSource >> At the first, I use AioContext instead of GSource, but after discussion, >> I think with GSource, we can integrated with glib more closely. > > Integrating with glib by itself is pointless. What is the *benefit*? > > We have a pretty good idea of how to make multithreaded device models > using AioContext, since we are using it for the block layer and > virtio-blk dataplane. Doing the same work twice, on two different > frameworks, doesn't seem like a very good idea. Hrm, I had thought on previous threads there was clear agreement that we did not want to use AioContext outside of the block layer. I think we certainly all agree that moving to a thread aware event loop is a necessary step toward multi-threading. I think the only question is whether to use AioContext or glib. AioContext is necessary for the block layer because the block layer still has synchronous I/O. I think we should aim to replace all sync I/O in the long term with coroutine based I/O. That lets us eliminate AioContextes entirely which is nice as the semantics are subtle. I think that's a solid argument for glib over AioContext. The former is well understood, documented, and makes unit testing easier. Did you have a specific concern with using glib vs. AioContext? Is it about reusing code in the block layer where AioContext is required? Regards, Anthony Liguori > > Paolo