[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v3 0/5] port network layer onto glib
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [RFC PATCH v3 0/5] port network layer onto glib |
Date: |
Fri, 12 Apr 2013 09:44:06 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Thu, Apr 11, 2013 at 08:05:05PM +0800, liu ping fan wrote:
> On Thu, Apr 11, 2013 at 7:44 PM, Stefan Hajnoczi <address@hidden> wrote:
> > On Thu, Apr 11, 2013 at 11:13 AM, liu ping fan <address@hidden> wrote:
> >> On Wed, Apr 10, 2013 at 7:55 PM, Stefan Hajnoczi <address@hidden> wrote:
> >>> On Wed, Apr 10, 2013 at 03:47:15PM +0800, liu ping fan wrote:
> >>>> On Tue, Apr 9, 2013 at 11:22 PM, Stefan Hajnoczi <address@hidden> wrote:
> >>>> > On Mon, Apr 08, 2013 at 01:36:03PM +0800, Liu Ping Fan wrote:
> >>>> >> This series focus on network backend (excluding slirp). The related
> >>>> >> patch
> >>>> >> for core's re-entrant (queue.c net.c) will be sent out separatelly.
> >>>> >
> >>>> > Are changes required to tap-win32.c?
> >>>> >
> >>>> Yes, needed. I will modify and verify it on win32.
> >>>>
> >>>> > Are you working on converting slirp?
> >>>> >
> >>>> slirp/ is a relative isolated system from net, need I covert it at the
> >>>> same time? Will start on it if needed.
> >>>
> >>> I suggest tackling it so we can be sure there aren't any surprises that
> >>> break the new model that you're introducing.
> >>>
> >> Oh, the slirp event driven mechanism is a little complicated. I
> >> think that it can be fixed with custom-built GSource prepare and
> >> dispatch function. Finally, each SlirpState associated with a GSource
> >> can run on different thread. Is this extra GSource acceptable?
> >
> > Yes, a SlirpState should be bound to an event loop.
> >
> > Is the reason you need new GSource code because slirp uses
> > GIOConditions beyond just G_IO_IN/G_IO_OUT? I think the generic
>
> This is a minor reason. I think the main challenge is that Slirp has
> many socket and even worse, the socket number is increased when new
> connection need to be set up.
So you want to avoid creating many GSources and instead have a single
custom GSource poll many fds?
That sounds like a generic utility so please make it reusable and not
part of slirp code.
Stefan
- Re: [Qemu-devel] [RFC PATCH v3 1/5] net: introduce glib function for network, (continued)