From: Walker, Benjamin <benjamin.walker at intel.com>
To: spdk@lists.01.org
Subject: Re: [SPDK] Adding Namespaces dynamically
Date: Tue, 21 Feb 2017 18:08:34 +0000 [thread overview]
Message-ID: <1487700509.38737.26.camel@intel.com> (raw)
In-Reply-To: CAGYjvj1xpTS4ifuLqv9rsm49ByE7vTmfJabworpBUoz1QdmJvQ@mail.gmail.com
[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]
On Sat, 2017-02-18 at 21:16 +0530, Sriram Popuri wrote:
> Hi experts,
>
>
> I am exploring spdk and particularly nvmf_tgt app. I would like to
> know how we can add namespaces dynamically.
> The app is reading from a conf file during initialization and doesn't
> seem to have an option to add namespaces dynamically.
> There is a way to add Namespace (spdk_nvmf_subsystem_add_ns), however
> that seems to be only during initialization (either through conf or
> rpc).
The NVMe-oF target currently has two distinct modes for its subsystems
- Direct and Virtual. We're working to unify these and make life a bit
simpler for everyone, but for now we'll need to treat them separately.
For direct mode, the subsystem exported is identical to a physical NVMe
subsystem attached to the target system. We're just exporting a
physical device over the network exactly as it is, with the absolute
minimum amount of virtualization required by the NVMe-oF specification.
All commands from the initiator simply pass through the NVMe-oF layer
and are forwarded directly to the backing SSD. In this case, adding
namespaces dynamically requires the backing NVMe SSD to support dynamic
namespaces. If the SSD supports it, then it should[1] work today.
For virtual mode, the NVMe-oF target is exporting a virtualized NVMe
subsystem that may be backed by any type of device. This requires our
target to emulate lots of functionality that the backing device may or
may not actually support. Adding namespaces through the config file is
only for virtual mode. We could of course emulate all of namespace
management in virtual mode, and we definitely should, but the code to
do this has not been implemented yet.
> Even if I invoke this api somehow, there are no AER commands
> implemented or the relevant log pages (in this case: 04h - Changed
> namespace list) so the host can discover the new namespace.
1. AER isn't emulated in virtual mode today, which is a problem. Even
in direct mode AER isn't fully set up today, although we have someone
working on this part now.
>
> Is this in plan and if so when can we expect to see this coming?
>
> Regards,
> ~Sriram
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3274 bytes --]
next reply other threads:[~2017-02-21 18:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-21 18:08 Walker, Benjamin [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-02-18 15:46 [SPDK] Adding Namespaces dynamically Sriram Popuri
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=1487700509.38737.26.camel@intel.com \
--to=spdk@lists.01.org \
/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.