WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 3/4] [Net] Support Xen accelerated network plugin modules
From: Kieran Mansley <kmansley@xxxxxxxxxxxxxx>
Date: Tue, 22 May 2007 15:20:01 +0100
Cc: muli@xxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Stephen Hemminger <shemminger@xxxxxxxxxxxxxxxxxxxx>, herbert@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 22 May 2007 07:18:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C278B79D.F53F%keir@xxxxxxxxxxxxx>
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>
References: <C278B79D.F53F%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2007-05-22 at 15:07 +0100, Keir Fraser wrote:
> On 22/5/07 13:44, "Kieran Mansley" <kmansley@xxxxxxxxxxxxxx> wrote:
> 
> >> 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.
> 
> Are there still module reference counts? If so, functions which may block
> can manipulate their module's reference count.
> 
> Or if not, I guess the accelerator module can have a private reference count
> checked by whatever unload function gets called from the RCU subsystem. So
> that unload becomes deferred until *both* an RCU phase has passed *and* a
> reference count has fallen to zero.

That's true I suppose, but it replaces the current spinlock and ref
count with an RCU and a ref count, so does little to address the
complexity that Stephen Hemminger was rightly concerned about.  It does
I suppose put the complexity in the plugin module rather than netfront,
and only have it when necessary, which might make it better, but makes
the job of writing the plugin modules harder and more prone to bugs. 

Kieran


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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