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 0/5] hw/block/nvme: support multi-path for ctrl/ns
Date: Fri, 15 Jan 2021 14:57:45 +0100 [thread overview]
Message-ID: <YAGfWe+OMxiBggh3@apples.localdomain> (raw)
In-Reply-To: <20210115120558.29313-1-minwoo.im.dev@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4552 bytes --]
On Jan 15 21:05, Minwoo Im wrote:
> Hello,
>
> This series added support for multi-path I/O with multi-controllers and
> namespace sharing. By supporting these features, we can test Linux
> kernel mpath(multi-path) code with this NVMe device.
>
> Patches from the first to third added multi-controller support in a NVM
> subsystem by adding a mpath.ctrl parameter to nvme device. The rest of
> the patches added namespace sharing support in a NVM subsystem with two
> or more controllers by adding mpath.ns parameter to nvme-ns device.
>
> Multi-path enabled in kernel with this series for two controllers with a
> namespace:
>
> root@vm:~/work# nvme list -v
> NVM Express Subsystems
>
> Subsystem Subsystem-NQN Controllers
> ---------------- ------------------------------------------------------------------------------------------------ ----------------
> nvme-subsys0 nqn.2019-08.org.qemu:serial nvme0, nvme1
>
> NVM Express Controllers
>
> Device SN MN FR TxPort Address Subsystem Namespaces
> -------- -------------------- ---------------------------------------- -------- ------ -------------- ------------ ----------------
> nvme0 serial QEMU NVMe Ctrl 1.0 pcie 0000:01:00.0 nvme-subsys0 nvme0n1
> nvme1 serial QEMU NVMe Ctrl 1.0 pcie 0000:02:00.0 nvme-subsys0 nvme0n1
>
> NVM Express Namespaces
>
> Device NSID Usage Format Controllers
> ------------ -------- -------------------------- ---------------- ----------------
> nvme0n1 1 268.44 MB / 268.44 MB 512 B + 0 B nvme0, nvme1
>
> The reason why I put 'RFC' tag to this series is mostly about the last
> patch "hw/block/nvme: add namespace sharing param for mpath". It seems
> like QEMU block backing device does not support to be shared among two
> or more -device(s). It means that we just can't give same drive=
> property to multiple nvme-ns devices. This patch has just let -device
> maps to -drive one-to-one(1:1), but if namespae sharing is detected and
> setup by the host kernel, then a single block device will be selected
> for the NVM subsystem. I'm not sure this is a good start for this
> feature, so I put the RFC tag here.
>
> Please kindly review!
>
Hi Minwoo,
First - super awesome that we get this discussion going. I've been
hacking around this a couple of times, but I've never been happy with
the approach.
As you already mentioned, the problem I see with this approach is that
we have separate namespaces attached to separate controllers. So we are
faking it to the max and if I/O starts going through the other
controller we end up on a namespace that is unrelated (different data).
Havoc ensues.
My approach looks a lot like yours, but I hacked around this by adding
extra 'ctrl-0', 'ctrl-1', ..., link-parameters to the namespace device,
replacing the bus. This works well because the namespace then just
registers with multiple controllers. But adding more parameters like
that just isnt nice, so I've been trying to figure out how to allow a
parameter to be specified multiple times, so we could just do more
'ctrl'-parameters.
Alas, since I started thinking about namespace sharing I have been
regretting that I didn't reverse the bus-mechanic for namespace
attachment. It would align better with the theory of operation if it was
the controllers that attached to namespaces, and not the other way
around. So what I would actually really prefer, is that we had multiple
'ns' link parameters on the controller device.
-device nvme-ns,id=a,nsid=1,...
-device nvme-ns,id=b,nsid=2,...
-device nvme-ns,id=c,nsid=3,...
-device nvme,cntlid=0,serial=foo,ns=a,ns=b
-device nvme,cntlid=1,serial=foo,ns=a,ns=c
But I havn't been able to figure out how to kick QOM into doing this.
And I'm definitely not sure this is the way to go. Should we instead
introduce a 'nvme-subsys' device and walk a bus?
I'd really appreciate some input on how we should model this if anyone
has any thoughts. And I think we should consider stuff like detached
namespaces as well. Support for Namespace Management. The whole shabang.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-01-15 14:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-15 12:05 [RFC PATCH 0/5] hw/block/nvme: support multi-path for ctrl/ns Minwoo Im
2021-01-15 12:05 ` [RFC PATCH 1/5] hw/block/nvme: add controller id parameter Minwoo Im
2021-01-15 12:05 ` [RFC PATCH 2/5] nvme: add CMIC enum value for Identify Controller Minwoo Im
2021-01-15 12:05 ` [RFC PATCH 3/5] hw/block/nvme: add multi-controller param for mpath Minwoo Im
2021-01-15 12:05 ` [RFC PATCH 4/5] nvme: add NMIC enum value for Identify Namespace Minwoo Im
2021-01-15 12:05 ` [RFC PATCH 5/5] hw/block/nvme: add namespace sharing param for mpath Minwoo Im
2021-01-15 13:57 ` Klaus Jensen [this message]
2021-01-15 17:35 ` [RFC PATCH 0/5] hw/block/nvme: support multi-path for ctrl/ns Keith Busch
2021-01-15 17:47 ` Klaus Jensen
2021-01-15 17:53 ` Keith Busch
2021-01-15 18:38 ` 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=YAGfWe+OMxiBggh3@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).