From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36532) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDXCN-0001vo-3A for qemu-devel@nongnu.org; Thu, 07 Mar 2013 04:33:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDXCL-00033e-LO for qemu-devel@nongnu.org; Thu, 07 Mar 2013 04:33:15 -0500 Received: from mail-ea0-x232.google.com ([2a00:1450:4013:c01::232]:54727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDXCL-00033V-F0 for qemu-devel@nongnu.org; Thu, 07 Mar 2013 04:33:13 -0500 Received: by mail-ea0-f178.google.com with SMTP id a14so1474508eaa.37 for ; Thu, 07 Mar 2013 01:33:12 -0800 (PST) Date: Thu, 7 Mar 2013 10:33:09 +0100 From: Stefan Hajnoczi Message-ID: <20130307093309.GD13854@stefanha-thinkpad.redhat.com> References: <1362316883-7948-1-git-send-email-qemulist@gmail.com> <20130305213046.GI21850@vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 0/3] *** make netlayer re-entrant *** List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Paolo Bonzini , "Michael S. Tsirkin" , mdroth , Anthony Liguori , qemu-devel@nongnu.org On Thu, Mar 07, 2013 at 10:06:52AM +0800, liu ping fan wrote: > On Wed, Mar 6, 2013 at 5:30 AM, mdroth wrote: > > On Sun, Mar 03, 2013 at 09:21:19PM +0800, Liu Ping Fan wrote: > >> From: Liu Ping Fan > >> > >> This series aim to make netlayer re-entrant, so netlayer can > >> run out of biglock safely. > > > > I think most of the locking considerations are still applicable either > > way, but this series seems to be written under the assumption that > > we'll be associating hubs/ports with separate AioContexts to facilitate > > driving the event handling outside of the iothread. Is this the case? > > > Yes. > > From what I gathered from the other thread, the path forward was to > > replace the global iohandler list that we currently use to drive > > NetClient events and replace it with a GSource and GMainContext, rather > > than relying on AioContexts. > > > Not quite sure about it. Seems that AioContext is built on GSource, so > I think they are similar, and AioContext is easy to reuse. > > > I do agree that the event handlers currently grouped under > > iohandler.c:io_handlers look like a nice fit for AioContexts, but other > > things like slirp and chardevs seem better served by a more general > > mechanism like GSources/GMainContexts. The chardev flow control patches > > seem to be doing something similar already as well. > > > I have made some fix for this series, apart from the concert about > GSource/ AioContext. Hope to discuss it clearly in next version and > fix it too. BTW what can we benefit from AioContext besides those from > GSource One thing I forgot to add: net/ doesn't use BH or qemu_aio_set_fd_handler() so AioContext isn't strictly necessary. Stefan