From: Keir Fraser <keir@xensource.com>
To: Kieran Mansley <kmansley@solarflare.com>,
Keir Fraser <keir@xensource.com>
Cc: <muli@il.ibm.com>, <netdev@vger.kernel.org>,
<xen-devel@lists.xensource.com>,
Stephen Hemminger <shemminger@linux-foundation.org>,
<herbert@gondor.apana.org.au>
Subject: Re: [Xen-devel] Re: [PATCH 3/4] [Net] Support Xen accelerated network plugin modules
Date: Tue, 22 May 2007 15:07:09 +0100 [thread overview]
Message-ID: <C278B79D.F53F%keir@xensource.com> (raw)
In-Reply-To: <1179837868.28562.22.camel@moonstone.uk.level5networks.com>
On 22/5/07 13:44, "Kieran Mansley" <kmansley@solarflare.com> 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.
-- Keir
WARNING: multiple messages have this Message-ID (diff)
From: Keir Fraser <keir@xensource.com>
To: Kieran Mansley <kmansley@solarflare.com>,
Keir Fraser <keir@xensource.com>
Cc: muli@il.ibm.com, netdev@vger.kernel.org,
xen-devel@lists.xensource.com,
Stephen Hemminger <shemminger@linux-foundation.org>,
herbert@gondor.apana.org.au
Subject: Re: [Xen-devel] Re: [PATCH 3/4] [Net] Support Xen accelerated network plugin modules
Date: Tue, 22 May 2007 15:07:09 +0100 [thread overview]
Message-ID: <C278B79D.F53F%keir@xensource.com> (raw)
In-Reply-To: <1179837868.28562.22.camel@moonstone.uk.level5networks.com>
On 22/5/07 13:44, "Kieran Mansley" <kmansley@solarflare.com> 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.
-- Keir
next prev parent reply other threads:[~2007-05-22 14:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-18 13:16 [PATCH 3/4] [Net] Support Xen accelerated network plugin modules Kieran Mansley
2007-05-21 17:50 ` Stephen Hemminger
2007-05-22 7:00 ` Kieran Mansley
2007-05-21 17:52 ` Stephen Hemminger
2007-05-22 7:15 ` Kieran Mansley
2007-05-22 7:28 ` Kieran Mansley
2007-05-22 7:48 ` [Xen-devel] " Keir Fraser
2007-05-22 7:48 ` Keir Fraser
2007-05-22 7:59 ` Kieran Mansley
2007-05-22 12:44 ` Kieran Mansley
2007-05-22 14:07 ` Keir Fraser [this message]
2007-05-22 14:07 ` Keir Fraser
2007-05-22 14:20 ` Kieran Mansley
2007-05-22 15:05 ` Stephen Hemminger
2007-05-22 16:06 ` Kieran Mansley
2007-05-25 6:53 ` Andi Kleen
2007-05-21 17:54 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C278B79D.F53F%keir@xensource.com \
--to=keir@xensource.com \
--cc=herbert@gondor.apana.org.au \
--cc=kmansley@solarflare.com \
--cc=muli@il.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.