[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 0/5] hw/block/nvme: support multi-path for ctrl/ns
From: |
Klaus Jensen |
Subject: |
Re: [RFC PATCH 0/5] hw/block/nvme: support multi-path for ctrl/ns |
Date: |
Fri, 15 Jan 2021 18:47:20 +0100 |
On Jan 15 09:35, Keith Busch wrote:
> On Fri, Jan 15, 2021 at 02:57:45PM +0100, Klaus Jensen wrote:
> >
> > 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.
>
> Would this work better if we introduce a new device in the nvme hierarchy:
> the nvme-subsystem? You could attach multi-path namespaces and
> controllers to that, and namespaces you don't want shared can attach
> directly to controllers like they do today. You could also auto-assign
> cntlid, and you wouldn't need to duplicate serial numbers in your
> parameters.
I kinda POC'ed that, but I think I tried to make it work with a bus and
walking it and all kinds of fancy stuff.
I think it can just be a 'link' parameter, so something like:
-device nvme-subsys,id=subsys0
-device nvme,id=nvme0,subsys=subsys0
-device nvme,id=nvme1,subsys=subsys0
-device nvme-ns,id=shared-ns1,nsid=1,subsys=subsys0
-device nvme-ns,id=private-ns2,nsid=2,bus=nvme0
When a controller "registers" with the subsystem it attaches to all
namespaces known, and when a namespace attaches, it attaches to all
controllers known. We can even add a 'detached' bool parameter to the
namespace and keep controllers from attaching, but allowing for later
attachment.
Cool!
Question: NSIDs must be the same on each controller for shared
namespaces, but can private namespaces "share" nsid across controllers
in the subsystem? I don't think the spec is clear on that point.
signature.asc
Description: PGP signature
- [RFC PATCH 0/5] hw/block/nvme: support multi-path for ctrl/ns, Minwoo Im, 2021/01/15
- [RFC PATCH 1/5] hw/block/nvme: add controller id parameter, Minwoo Im, 2021/01/15
- [RFC PATCH 3/5] hw/block/nvme: add multi-controller param for mpath, Minwoo Im, 2021/01/15
- [RFC PATCH 2/5] nvme: add CMIC enum value for Identify Controller, Minwoo Im, 2021/01/15
- [RFC PATCH 4/5] nvme: add NMIC enum value for Identify Namespace, Minwoo Im, 2021/01/15
- [RFC PATCH 5/5] hw/block/nvme: add namespace sharing param for mpath, Minwoo Im, 2021/01/15
- Re: [RFC PATCH 0/5] hw/block/nvme: support multi-path for ctrl/ns, Klaus Jensen, 2021/01/15