qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v2 1/4] net: port tap onto glib


From: liu ping fan
Subject: Re: [Qemu-devel] [RFC PATCH v2 1/4] net: port tap onto glib
Date: Tue, 9 Apr 2013 13:12:39 +0800

On Mon, Apr 8, 2013 at 7:44 PM, Stefan Hajnoczi <address@hidden> wrote:
> On Wed, Apr 03, 2013 at 05:28:39PM +0800, liu ping fan wrote:
>> On Thu, Mar 28, 2013 at 10:32 PM, Stefan Hajnoczi <address@hidden> wrote:
>> > On Thu, Mar 28, 2013 at 03:55:52PM +0800, Liu Ping Fan wrote:
>> >> From: Liu Ping Fan <address@hidden>
>> >>
>> >> Bind each NetClientState with a GSource(ie,NetClientSource). Currently,
>> >> these GSource attached with default context, but in future, after
>> >> resolving the race between handlers and the interface exposed by 
>> >> NetClientInfo
>> >> and other re-entrant issue,  we can run NetClientState on different 
>> >> threads
>> >>
>> >> Signed-off-by: Liu Ping Fan <address@hidden>
>> >> ---
>> >>  include/net/net.h |   27 +++++++++++++++
>> >>  net/net.c         |   96 
>> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >>  net/tap.c         |   57 +++++++++++++++++++++++++------
>> >>  3 files changed, 169 insertions(+), 11 deletions(-)
>> >
>> > Please split this into two patches:
>> >
>> > 1. NetClientSource
>> > 2. Convert tap to NetClientSource
>> >
>> > Once you do that it turns out that NetClientSource has nothing to do
>> > with the net subsystem, it's a generic file descriptor GSource (weird
>> > that glib doesn't already provide this abstraction).
>> >
>> > Each net client needs to reimplement .bind_ctx() anyway, so I don't see
>> > much point in having NetClientSource.nsrc[].  We might as well let net
>> > clients have that field themselves and destroy the GSource in their
>> > destructor function.
>> >
>> The only way to detach the GSource from GMainContext is
>> g_source_destroy, so if we want to re-bind nc from threadA to threadB,
>>  we should destroy the old one and create a new. Is that meaningful?
>
> I guess that can be done.
>
> What I was really thinking when I suggested getting rid of nsrc[] is
> that it's a little ugly to have the array with 2 GSources.  Different
> net clients have different numbers of GSources - 0 for NICs, 1 for most
> backends, 2 for ioeventfd for virtio-net data plane with separate rx/tx.
>
> So my thought was to leave the number of GSources in the layer that uses
> them - each specific net client.
>
OK, see. What about nsrc[0] at the end of struct or **nsrc ?

> Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]