From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59591) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULGsu-0007MB-97 for qemu-devel@nongnu.org; Thu, 28 Mar 2013 13:45:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ULGss-0006Qm-FG for qemu-devel@nongnu.org; Thu, 28 Mar 2013 13:45:08 -0400 Received: from mail-qa0-f53.google.com ([209.85.216.53]:61792) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULGss-0006QS-B6 for qemu-devel@nongnu.org; Thu, 28 Mar 2013 13:45:06 -0400 Received: by mail-qa0-f53.google.com with SMTP id k4so21691qaq.5 for ; Thu, 28 Mar 2013 10:45:05 -0700 (PDT) Sender: fluxion Date: Thu, 28 Mar 2013 12:41:50 -0500 From: mdroth Message-ID: <20130328174150.GE8146@vm> References: <1364457355-4119-1-git-send-email-qemulist@gmail.com> <20130328145552.GK22865@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130328145552.GK22865@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH v2 0/4] port network layer onto glib List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Paolo Bonzini , Anthony Liguori , Liu Ping Fan , qemu-devel@nongnu.org On Thu, Mar 28, 2013 at 03:55:52PM +0100, Stefan Hajnoczi wrote: > On Thu, Mar 28, 2013 at 03:55:51PM +0800, Liu Ping Fan wrote: > > From: Liu Ping Fan > > > > These series aim to make the whole network re-entrant, here only apply backend and frontend, > > and for the netcore, separated patches have been sent out. All of these will prepare us for > > moving towards making network layer mutlit-thread. > > Finally it would be omething like > > qemu -object io-thread,id=thread0 \ > > -device virtio-net,rx[0]=thread0,tx[0]=thread0 > > > > The brief of the whole aim and plan is documented on > > http://wiki.qemu.org/Features/network_reentrant > > > > The main issue is about GSource or AioContext, > > http://marc.info/?t=136315453300002&r=1&w=3 > > And I sumary the main points: > > disadvantage for current AioContext > > 1st. need to define and expand interface for other fd events, while glib open this interface for user * > > 2nd. need to add support for IOCanReadHandler, while gsource provide prepare, check method to allow more flexible control > > 3rd. block layer's AioContext will block other AioContexts on the same thread. > > 4th. need more document > > disadvantage for glib > > 1st. if more than one fds on the same GSource, need re-implement something like aio_set_file_handler > > > > Since I have successed to port frontend on glib, there is no obstale to use glib. > > > > > > v1->v2: > > 1.NetClientState can associate with up to 2 GSource, for virtio net, one for tx, one for rx, > > so vq can run on different threads. > > 2.make network front-end onto glib, currently virtio net dataplane > > > > > > Liu Ping Fan (4): > > net: port tap onto glib > > net: resolve race of tap backend and its peer > > net: port hub onto glib > > net: port virtio net onto glib > > > > hw/qdev-properties-system.c | 1 + > > hw/virtio-net.c | 165 +++++++++++++++++++++++++++++++++++++++++++ > > hw/virtio.c | 6 ++ > > hw/virtio.h | 2 + > > include/net/net.h | 27 +++++++ > > include/net/queue.h | 14 ++++ > > net/hub.c | 34 ++++++++- > > net/net.c | 97 +++++++++++++++++++++++++ > > net/queue.c | 4 +- > > net/tap.c | 62 +++++++++++++--- > > 10 files changed, 397 insertions(+), 15 deletions(-) > > It seems the AioContext vs glib issue hasn't been settled yet. My take > is that glib is preferrable *if* we don't need to write too many > helpers/wrappers on top (then we're basically back to rolling our own, > AioContext). > > I was surprised by the amount of code required to listen on a file > descriptor. Are you sure there isn't a glib way of doing this that > avoids rolling our own GSource? GIOChannel provides a pre-baked GSource you can pass around, but this might add more confusion to the mix when you consider things like Slirp which will likely require a custom GSource. It also assumes a different signature than GSourceFunc for the callback which further adds to the confusion. Keeping the interfaces centered around normal GSources I think would help to avoid the proliferation of more event-handling registration mechanisms in the future, and make conversions easier if we do need to change things. A generic GSource for handling FDs that we can re-use for basic use cases would help curtail some of the boilerplate later for common fd handlers. Probably doesn't make sense to generalize until we reach a decision on glib vs. aiocontext though. > > In the next series, please drop the hub re-entrancy stuff and virtio-net > data plane. Instead just focus on systematically moving existing net > clients onto the event loop (net/*.c and NICs). The only controversial > issue there is AioContext vs glib, and once that's settled we can merge > the patches. > > Please avoid layering violations - for example a comment about > virtio-net in net.h, a comment about vhost in tap, or putting > net_source_funcs in net.h. I think converting all existing net clients > will help make the code changes appropriate and eliminate these kinds of > hacks which are because you're focussing just on virtio, tap, and hub > here. > > Stefan >