From: "J. Bruce Fields" <bfields@fieldses.org>
To: Stanislav Kinsbursky <skinsbursky@parallels.com>
Cc: "Trond.Myklebust@netapp.com" <Trond.Myklebust@netapp.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
Pavel Emelianov <xemul@parallels.com>,
"neilb@suse.de" <neilb@suse.de>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"devel@openvz.org" <devel@openvz.org>
Subject: Re: [PATCH v3 0/3] SUNRPC: rcbind clients virtualization
Date: Fri, 4 Nov 2011 18:10:45 -0400 [thread overview]
Message-ID: <20111104221045.GL721@fieldses.org> (raw)
In-Reply-To: <4EAA78DD.2000408@parallels.com>
On Fri, Oct 28, 2011 at 01:41:49PM +0400, Stanislav Kinsbursky wrote:
> 28.10.2011 13:30, J. Bruce Fields пишет:
> >On Fri, Oct 28, 2011 at 01:24:45PM +0400, Stanislav Kinsbursky wrote:
> >>This patch-set was created before you've sent your NFSd plan and we
> >>disacussed Lockd per netns.
> >>So, this sentence: "NFSd service will be per netns too from my pow"
> >>is obsolete. And Lockd will be one for all.
> >
> >I believe lockd should be pert-netns--at least that's what the server
> >needs.
> >
> >(The single lockd thread may handle requests from all netns, but it
> >should behave like a different service depending on netns, so its data
> >structures, etc. will need to be per-ns.
> >
>
> Sure. Looks like we have misunderstanding here. When I said, that
> Lockd should be one for all, I meaned, that we will have only one
> kthread for all ns (not one per ns). Private data will be per net
> ns, of course.
>
> BTW, Bruce, please, have a brief look at my e-mail to
> linux-nfs@vger.kernel.org named "SUNRPC: non-exclusive pipe
> creation".
> I've done a lot in "RPC pipefs per net ns" task, and going to send
> first patches soon. But right now I'm really confused will this
> non-exclusive pipes creation and almost ready so remove this
> functionality. But I'm afraid, that I've missed something. Would be
> greatly appreciate for your opinion about my question.
Sorry for the delay--it looks reasonable to me on a quick skim, but I'm
assuming it's Trond that will need to review this.
--b.
>
> >--b.
> >
> >>Or you are asking about something else?
> >>
> >>>--b.
> >>>
> >>>>And also we have NFSd file system, which
> >>>>is not virtualized yet.
> >>>>
> >>>>The following series consists of:
> >>>>
> >>>>---
> >>>>
> >>>>Stanislav Kinsbursky (3):
> >>>> SUNRPC: move rpcbind internals to sunrpc part of network namespace context
> >>>> SUNRPC: optimize net_ns dereferencing in rpcbind creation calls
> >>>> SUNRPC: optimize net_ns dereferencing in rpcbind registering calls
> >>>>
> >>>>
> >>>> net/sunrpc/netns.h | 5 ++
> >>>> net/sunrpc/rpcb_clnt.c | 103 ++++++++++++++++++++++++++----------------------
> >>>> 2 files changed, 61 insertions(+), 47 deletions(-)
> >>>>
> >>>>--
> >>>>Signature
> >>
> >>
> >>--
> >>Best regards,
> >>Stanislav Kinsbursky
>
>
> --
> Best regards,
> Stanislav Kinsbursky
next prev parent reply other threads:[~2011-11-04 22:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-27 19:10 [PATCH v3 0/3] SUNRPC: rcbind clients virtualization Stanislav Kinsbursky
2011-10-27 19:11 ` [PATCH v3 1/3] SUNRPC: move rpcbind internals to sunrpc part of network namespace context Stanislav Kinsbursky
2011-10-27 19:11 ` [PATCH v3 2/3] SUNRPC: optimize net_ns dereferencing in rpcbind creation calls Stanislav Kinsbursky
2011-10-27 19:11 ` Stanislav Kinsbursky
2011-10-27 19:30 ` [PATCH v3 3/3] SUNRPC: optimize net_ns dereferencing in rpcbind registering calls Stanislav Kinsbursky
2011-10-27 20:25 ` [PATCH v3 0/3] SUNRPC: rcbind clients virtualization J. Bruce Fields
2011-10-28 9:24 ` Stanislav Kinsbursky
2011-10-28 9:30 ` J. Bruce Fields
2011-10-28 9:41 ` Stanislav Kinsbursky
2011-11-04 22:10 ` J. Bruce Fields [this message]
2011-11-07 8:02 ` Stanislav Kinsbursky
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=20111104221045.GL721@fieldses.org \
--to=bfields@fieldses.org \
--cc=Trond.Myklebust@netapp.com \
--cc=davem@davemloft.net \
--cc=devel@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
--cc=skinsbursky@parallels.com \
--cc=xemul@parallels.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.