[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z0ClxgBJG_YBF-Ql@kbusch-mbp.dhcp.thefacebook.com>
Date: Fri, 22 Nov 2024 08:39:50 -0700
From: Keith Busch <kbusch@...nel.org>
To: Christoph Hellwig <hch@....de>
Cc: Bryan Gurney <bgurney@...hat.com>, linux-kernel@...r.kernel.org,
linux-nvme@...ts.infradead.org, sagi@...mberg.me, axboe@...nel.dk,
mpe@...erman.id.au, naveen@...nel.org, maddy@...ux.ibm.com,
kernel@...0n.name, jmeneghi@...hat.com, bmarzins@...hat.com
Subject: Re: [PATCH 1/1] nvme: always enable multipath
On Fri, Nov 22, 2024 at 01:09:25PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 21, 2024 at 05:03:21PM -0500, Bryan Gurney wrote:
> > Since device-mapper multipath will no longer be operating on NVMe
> > devices, there is no longer a need to set CONFIG_NVME_MULTIPATH=n.
> >
> > Always enable NVMe multipath, remove CONFIG_NVME_MULTIPATH, and use
> > the code paths that would be used if CONFIG_NVME_MULTIPATH=y.
>
> As mentioned last round not having to build the not tiny multipath
> code for embedded systems and other small builds that never require
> multipathing still seems like a sensible idea.
It's not just embedded either. I have plenty of single port datacenter
PCIe NVMe's that claim multi-controller capabilities. I think it's some
artifact of SRIOV that some versions of the firmware can bring.
Anyway, we only use the one physical function, so they're certainly not
multipath devices here. We disable the CONFIG option because while the
nvme multipath IO overhead is low, it's not zero.
Powered by blists - more mailing lists