This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH 3/4] [Net] Support Xen accelerated network pl

To: Kieran Mansley <kmansley@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 3/4] [Net] Support Xen accelerated network plugin modules
From: Stephen Hemminger <shemminger@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 22 May 2007 08:05:12 -0700
Cc: muli@xxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>, herbert@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 23 May 2007 02:17:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1179837868.28562.22.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Linux Foundation
References: <C2785EC4.F4E3%keir@xxxxxxxxxxxxx> <1179837868.28562.22.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 22 May 2007 13:44:28 +0100
Kieran Mansley <kmansley@xxxxxxxxxxxxxx> wrote:

> On Tue, 2007-05-22 at 08:48 +0100, Keir Fraser wrote:
> > 
> > 
> > On 22/5/07 08:28, "Kieran Mansley" <kmansley@xxxxxxxxxxxxxx> wrote:
> > 
> > > On Tue, 2007-05-22 at 08:15 +0100, Kieran Mansley wrote:
> > >> RCU on its own wouldn't
> > >> prevent the accelerated plugin being unloaded while netfront was using
> > >> one of the hooks.
> > > 
> > > Hmm, actually I think it could be used to do that.  I'll take a look.
> > 
> > Eagerly zap the function pointers, then wait one RCU period so every CPU
> > goes through a quiescent point before unloading the module?
> > 
> >  -- Keir
> Am I right in thinking that if one of the functions that was protected
> by RCU was to block, that would be a bad thing?  Clearly the data path
> hooks can't/don't block, but I'm not sure it's so obvious for things
> like probing a new device. 
> Kieran

The same thing is already done to handle network protocols already.
RCU is used for the object handle (including function pointers).
You need to use:
  * put rcu structure in accelerator list member
    and initialize it to the callback
  * on addition increase refcount
on deletion
  * call list_del_rcu() on removal
  * in rcu callback you do last step
        like drop module refcount and free.

Stephen Hemminger <shemminger@xxxxxxxxxxxxxxxxxxxx>

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>