Re: [Qemu-devel] [RFC PATCH v3 0/5] port network layer onto glib
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 stefa...@gmail.com wrote: On Thu, Apr 11, 2013 at 11:13 AM, liu ping fan qemul...@gmail.com wrote: On Wed, Apr 10, 2013 at 7:55 PM, Stefan Hajnoczi stefa...@redhat.com 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 stefa...@redhat.com 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 0/5] port network layer onto glib
On Wed, Apr 10, 2013 at 7:55 PM, Stefan Hajnoczi stefa...@redhat.com 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 stefa...@redhat.com 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? Stefan
Re: [Qemu-devel] [RFC PATCH v3 0/5] port network layer onto glib
On Thu, Apr 11, 2013 at 11:13 AM, liu ping fan qemul...@gmail.com wrote: On Wed, Apr 10, 2013 at 7:55 PM, Stefan Hajnoczi stefa...@redhat.com 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 stefa...@redhat.com 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 fdsource GSource (currently called NetClientSource in your patches) should support that. This way fdsource can also be used by other socket code in QEMU. Stefan
Re: [Qemu-devel] [RFC PATCH v3 0/5] port network layer onto glib
On Thu, Apr 11, 2013 at 7:44 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Thu, Apr 11, 2013 at 11:13 AM, liu ping fan qemul...@gmail.com wrote: On Wed, Apr 10, 2013 at 7:55 PM, Stefan Hajnoczi stefa...@redhat.com 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 stefa...@redhat.com 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. Pingfan fdsource GSource (currently called NetClientSource in your patches) should support that. This way fdsource can also be used by other socket code in QEMU. Stefan
Re: [Qemu-devel] [RFC PATCH v3 0/5] port network layer onto glib
On Tue, Apr 9, 2013 at 11:22 PM, Stefan Hajnoczi stefa...@redhat.com 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. Regards, Pingfan Stefan
Re: [Qemu-devel] [RFC PATCH v3 0/5] port network layer onto glib
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 stefa...@redhat.com 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. Stefan
Re: [Qemu-devel] [RFC PATCH v3 0/5] port network layer onto glib
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? Are you working on converting slirp? Stefan
