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] [PATCH 4/4] [Net] Support accelerated network plugin mod

To: "Kieran Mansley" <kmansley@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 4/4] [Net] Support accelerated network plugin modules
From: "Zhu Han" <schumi.han@xxxxxxxxx>
Date: Fri, 15 Jun 2007 14:03:05 -0400
Cc: netdev@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, herbert@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 15 Jun 2007 11:01:05 -0700
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gBGCjRBp3jeBfIho0bQXkXoo8P0Z+tupgmbPH5fd/M+uLEngYI0lA7+mrpGz6D9JinrEvFcex/UCdDKBXLln/dP2Mnr/UdlsJyTyn7SBuH5yNYM31j7JMcrPB6Y4F8gttFGw+izs1rLGxeSRvU5KsMJ2tHFMJShLR3Lsu6F2OEU=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h94vU8zCdX26o+U4bXcUcPvb5M+Z/kEMNQ+IRMBIY9e3KnwxQ738krg2+bXfX1TVoL32/V/LYXPqAqN9wCT1Qq1g4Obt3/ZEi76TlNpiFtjl6i/d4UXw2D8S0NY693g+FOdEDF/K9n7p5Hn7ECCgyUPq8GHWmtq3M1dDyjg4R+A=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1181924563.4121.94.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>
References: <1181904393.4121.55.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4e777ed10706150859r3b6e1617o3b31e5e24a30e6c9@xxxxxxxxxxxxxx> <1181924563.4121.94.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 6/15/07, Kieran Mansley <kmansley@xxxxxxxxxxxxxx> wrote:

The lock protects the use_count variable.  The use_count variable
prevents the plugin module unloading while it is being used.  I couldn't
just use the lock to prevent the module unloading as the hook function
(i) might block (and holding a spin_lock would be rather antisocial)
(ii) might call back into netfront and try to take the lock again, which
would deadlock.


If the hook routine blocks on the other code path instead of tx/rx
path,  why not use a simple atomic reference count. When the reference
count reachs zero, free it. Considering you can synchronzie on tx/rx
path, the free will not happen under the critical code path. So the
uninitialize work could be done inside the free routine even if it
blocks.

I think that RCU would only work in this situation if the hook functions
didn't block,.

I agree.


Kieran








--
best regards,
hanzhu

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