qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Klaus Jensen <its@irrelevant.dk>
To: Minwoo Im <minwoo.im.dev@gmail.com>
Cc: Keith Busch <kbusch@kernel.org>, Kevin Wolf <kwolf@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [RFC PATCH V2 00/11] hw/block/nvme: support multi-path for ctrl/ns
Date: Mon, 18 Jan 2021 22:14:45 +0100	[thread overview]
Message-ID: <YAX6RcpFiX9xthQI@apples.localdomain> (raw)
In-Reply-To: <20210117145341.23310-1-minwoo.im.dev@gmail.com>

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

On Jan 17 23:53, Minwoo Im wrote:
> Hello,
> 
> This patch series introduces NVMe subsystem device to support multi-path
> I/O in NVMe device model.  Two use-cases are supported along with this
> patch: Multi-controller, Namespace Sharing.
> 
> V1 RFC has been discussed with Klaus and Keith, I really appreciate them
> for this patch series to have proper direction [1].
> 
> This patch series contains few start-up refactoring pathces from the
> first to fifth patches to make nvme-ns device not to rely on the nvme
> controller always.  Because nvme-ns shall be able to be mapped to the
> subsystem level, not a single controller level so that it should provide
> generic initialization code: nvme_ns_setup() with NvmeCtrl.  To do that,
> the first five patches are to remove the NvmeCtrl * instance argument
> from the nvme_ns_setup().  I'd be happy if they are picked!
> 
> For controller and namespace devices, 'subsys' property has been
> introduced to map them to a subsystem.  If multi-controller needed, we
> can specify 'subsys' to controllers the same.
> 
> For namespace deivice, if 'subsys' is not given just like it was, it
> will have to be provided with 'bus' parameter to specify a nvme
> controller device to attach, it means, they are mutual-exlusive.  To
> share a namespace between or among controllers, then nvme-ns should have
> 'subsys' property to a single nvme subsystem instance.  To make a
> namespace private one, then we need to specify 'bus' property rather
> than the 'subsys'.
> 
> Of course, this series does not require any updates for the run command
> for the previos users.
> 
> Plase refer the following example with nvme-cli output:
> 
> QEMU Run:
>   -device nvme-subsys,id=subsys0 \
>   -device nvme,serial=foo,id=nvme0,subsys=subsys0 \
>   -device nvme,serial=bar,id=nvme1,subsys=subsys0 \
>   -device nvme,serial=baz,id=nvme2,subsys=subsys0 \
>   -device nvme-ns,id=ns1,drive=drv10,nsid=1,subsys=subsys0 \
>   -device nvme-ns,id=ns2,drive=drv11,nsid=2,bus=nvme2 \
>   \
>   -device nvme,serial=qux,id=nvme3 \
>   -device nvme-ns,id=ns3,drive=drv12,nsid=3,bus=nvme3
> 
> nvme-cli:
>   root@vm:~/work# nvme list -v
>   NVM Express Subsystems
> 
>   Subsystem        Subsystem-NQN                                                                                    Controllers
>   ---------------- ------------------------------------------------------------------------------------------------ ----------------
>   nvme-subsys1     nqn.2019-08.org.qemu:subsys0                                                                     nvme0, nvme1, nvme2
>   nvme-subsys3     nqn.2019-08.org.qemu:qux                                                                         nvme3
> 
>   NVM Express Controllers
> 
>   Device   SN                   MN                                       FR       TxPort Address        Subsystem    Namespaces
>   -------- -------------------- ---------------------------------------- -------- ------ -------------- ------------ ----------------
>   nvme0    foo                  QEMU NVMe Ctrl                           1.0      pcie   0000:00:06.0   nvme-subsys1 nvme1n1
>   nvme1    bar                  QEMU NVMe Ctrl                           1.0      pcie   0000:00:07.0   nvme-subsys1 nvme1n1
>   nvme2    baz                  QEMU NVMe Ctrl                           1.0      pcie   0000:00:08.0   nvme-subsys1 nvme1n1, nvme1n2
>   nvme3    qux                  QEMU NVMe Ctrl                           1.0      pcie   0000:00:09.0   nvme-subsys3
> 
>   NVM Express Namespaces
> 
>   Device       NSID     Usage                      Format           Controllers
>   ------------ -------- -------------------------- ---------------- ----------------
>   nvme1n1      1        134.22  MB / 134.22  MB    512   B +  0 B   nvme0, nvme1, nvme2
>   nvme1n2      2        268.44  MB / 268.44  MB    512   B +  0 B   nvme2
>   nvme3n1      3        268.44  MB / 268.44  MB    512   B +  0 B   nvme3
> 
> Summary:
>   - Refactored nvme-ns device not to rely on controller during the
>     setup.  [1/11 - 5/11]
>   - Introduced a nvme-subsys device model. [6/11]
>   - Create subsystem NQN based on subsystem. [7/11]
>   - Introduced multi-controller model. [8/11 - 9/11]
>   - Updated namespace sharing scheme to be based on nvme-subsys
>     hierarchy. [10/11 - 11/11]
> 
> Since RFC V1:
>   - Updated namespace sharing scheme to be based on nvme-subsys
>     hierarchy.
> 

Great stuff Minwoo. Thanks!

I'll pick up [01-05/11] directly since they are pretty trivial.

The subsystem model looks pretty much like it should, I don't have a lot
of comments.

One thing that I considered, is if we should reverse the "registration"
and think about it as namespace attachment. The spec is about
controllers attaching to namespaces, not the other way around.
Basically, let the namespaces be configured first and register on the
subsystem (accumulating in a "namespaces" array), then have the
controllers register with the subsystem and attach to all "non-detached"
namespaces. This allows detached namespaces to "linger" in the subsystem
to be attached later on. If there are any private namespaces (like ns2
in your example above), it will be defined after the controller with the
bus=ctrlX parameter like normal.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2021-01-18 21:19 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-17 14:53 [RFC PATCH V2 00/11] hw/block/nvme: support multi-path for ctrl/ns Minwoo Im
2021-01-17 14:53 ` [RFC PATCH V2 01/11] hw/block/nvme: remove unused argument in nvme_ns_init_zoned Minwoo Im
2021-01-18 20:00   ` Klaus Jensen
2021-01-17 14:53 ` [RFC PATCH V2 02/11] hw/block/nvme: open code for volatile write cache Minwoo Im
2021-01-18 20:04   ` Klaus Jensen
2021-01-19  7:32   ` Klaus Jensen
2021-01-19  8:04     ` Minwoo Im
2021-02-11  6:45   ` Sai Pavan Boddu
2021-02-11  6:58     ` Sai Pavan Boddu
2021-01-17 14:53 ` [RFC PATCH V2 03/11] hw/block/nvme: remove unused argument in nvme_ns_init_blk Minwoo Im
2021-01-18 20:05   ` Klaus Jensen
2021-01-17 14:53 ` [RFC PATCH V2 04/11] hw/block/nvme: split setup and register for namespace Minwoo Im
2021-01-18 20:08   ` Klaus Jensen
2021-01-17 14:53 ` [RFC PATCH V2 05/11] hw/block/nvme: remove unused argument in nvme_ns_setup Minwoo Im
2021-01-18 20:09   ` Klaus Jensen
2021-01-17 14:53 ` [RFC PATCH V2 06/11] hw/block/nvme: introduce nvme-subsys device Minwoo Im
2021-01-17 14:53 ` [RFC PATCH V2 07/11] hw/block/nvme: support to map controller to a subsystem Minwoo Im
2021-01-17 14:53 ` [RFC PATCH V2 08/11] hw/block/nvme: add CMIC enum value for Identify Controller Minwoo Im
2021-01-17 14:53 ` [RFC PATCH V2 09/11] hw/block/nvme: support for multi-controller in subsystem Minwoo Im
2021-01-17 14:53 ` [RFC PATCH V2 10/11] hw/block/nvme: add NMIC enum value for Identify Namespace Minwoo Im
2021-01-18 20:25   ` Klaus Jensen
2021-01-19  2:12     ` Minwoo Im
2021-01-17 14:53 ` [RFC PATCH V2 11/11] hw/block/nvme: support for shared namespace in subsystem Minwoo Im
2021-01-18 21:14 ` Klaus Jensen [this message]
2021-01-19  3:21   ` [RFC PATCH V2 00/11] hw/block/nvme: support multi-path for ctrl/ns Minwoo Im
2021-01-19  6:04     ` Klaus Jensen
2021-01-19  7:51       ` Minwoo Im

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=YAX6RcpFiX9xthQI@apples.localdomain \
    --to=its@irrelevant.dk \
    --cc=kbusch@kernel.org \
    --cc=kwolf@redhat.com \
    --cc=minwoo.im.dev@gmail.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).