All of lore.kernel.org
 help / color / mirror / Atom feed
* [SPDK] Adding Namespaces dynamically
@ 2017-02-18 15:46 Sriram Popuri
  0 siblings, 0 replies; 2+ messages in thread
From: Sriram Popuri @ 2017-02-18 15:46 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

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).
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.

Is this in plan and if so when can we expect to see this coming?

Regards,
~Sriram

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 818 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [SPDK] Adding Namespaces dynamically
@ 2017-02-21 18:08 Walker, Benjamin
  0 siblings, 0 replies; 2+ messages in thread
From: Walker, Benjamin @ 2017-02-21 18:08 UTC (permalink / raw)
  To: spdk

[-- 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 --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-02-21 18:08 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-18 15:46 [SPDK] Adding Namespaces dynamically Sriram Popuri
2017-02-21 18:08 Walker, Benjamin

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.