From: Hannes Reinecke <hare@suse.de> To: Christoph Hellwig <hch@lst.de>, Mike Snitzer <snitzer@redhat.com> Cc: linux-nvme@lists.infradead.org, Keith Busch <keith.busch@intel.com>, Sagi Grimberg <sagi@grimberg.me>, axboe@kernel.dk, Martin Wilck <mwilck@suse.com>, lijie <lijie34@huawei.com>, xose.vazquez@gmail.com, chengjike.cheng@huawei.com, shenhong09@huawei.com, dm-devel@redhat.com, wangzhoumengjian@huawei.com, christophe.varoqui@opensvc.com, bmarzins@redhat.com, sschremm@netapp.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] nvme: allow ANA support to be independent of native multipathing Date: Fri, 16 Nov 2018 10:40:40 +0100 [thread overview] Message-ID: <37098edd-4dea-b58f-bca6-3be9af8ec4ee@suse.de> (raw) In-Reply-To: <20181116091458.GA17267@lst.de> On 11/16/18 10:14 AM, Christoph Hellwig wrote: > On Thu, Nov 15, 2018 at 12:46:05PM -0500, Mike Snitzer wrote: >> Whether or not ANA is present is a choice of the target implementation; >> the host (and whether it supports multipathing) has _zero_ influence on >> this. If the target declares a path as 'inaccessible' the path _is_ >> inaccessible to the host. As such, ANA support should be functional >> even if native multipathing is not. >> >> Introduce ability to always re-read ANA log page as required due to ANA >> error and make current ANA state available via sysfs -- even if native >> multipathing is disabled on the host (e.g. nvme_core.multipath=N). > > The first part I could see, but I still want to make it conditional > in some way as nvme is going into deeply embedded setups, and I don't > want to carry the weight of the ANA code around for everyone. > Can you clarify this a bit? We _do_ have the NVME multipath config option to deconfigure the whole thing during compile time; that isn't influenced with this patch. So are you worried about the size of the ANA implementation itself? Or are you worried about the size of the ANA structures? > The second I fundamentally disagree with. And even if you found agreement > it would have to be in a separate patch as it is a separate feature. > Why? Where's the problem with re-reading the ANA log pages if we get an event indicating that we should? Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
WARNING: multiple messages have this Message-ID (diff)
From: hare@suse.de (Hannes Reinecke) Subject: [PATCH] nvme: allow ANA support to be independent of native multipathing Date: Fri, 16 Nov 2018 10:40:40 +0100 [thread overview] Message-ID: <37098edd-4dea-b58f-bca6-3be9af8ec4ee@suse.de> (raw) In-Reply-To: <20181116091458.GA17267@lst.de> On 11/16/18 10:14 AM, Christoph Hellwig wrote: > On Thu, Nov 15, 2018@12:46:05PM -0500, Mike Snitzer wrote: >> Whether or not ANA is present is a choice of the target implementation; >> the host (and whether it supports multipathing) has _zero_ influence on >> this. If the target declares a path as 'inaccessible' the path _is_ >> inaccessible to the host. As such, ANA support should be functional >> even if native multipathing is not. >> >> Introduce ability to always re-read ANA log page as required due to ANA >> error and make current ANA state available via sysfs -- even if native >> multipathing is disabled on the host (e.g. nvme_core.multipath=N). > > The first part I could see, but I still want to make it conditional > in some way as nvme is going into deeply embedded setups, and I don't > want to carry the weight of the ANA code around for everyone. > Can you clarify this a bit? We _do_ have the NVME multipath config option to deconfigure the whole thing during compile time; that isn't influenced with this patch. So are you worried about the size of the ANA implementation itself? Or are you worried about the size of the ANA structures? > The second I fundamentally disagree with. And even if you found agreement > it would have to be in a separate patch as it is a separate feature. > Why? Where's the problem with re-reading the ANA log pages if we get an event indicating that we should? Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare at suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg GF: F. Imend?rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG N?rnberg)
next prev parent reply other threads:[~2018-11-16 9:40 UTC|newest] Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-08 6:09 [PATCH] multipath-tools: add ANA support for NVMe device lijie 2018-11-12 16:23 ` Martin Wilck 2018-11-12 21:53 ` Mike Snitzer 2018-11-12 21:53 ` Mike Snitzer 2018-11-13 6:59 ` Martin Wilck 2018-11-13 6:59 ` Martin Wilck 2018-11-13 16:18 ` Keith Busch 2018-11-13 16:18 ` Keith Busch 2018-11-13 18:00 ` Mike Snitzer 2018-11-13 18:00 ` Mike Snitzer 2018-11-14 5:38 ` Mike Snitzer 2018-11-14 5:38 ` Mike Snitzer 2018-11-14 7:49 ` Hannes Reinecke 2018-11-14 7:49 ` Hannes Reinecke 2018-11-14 10:36 ` [dm-devel] " Martin Wilck 2018-11-14 10:36 ` Martin Wilck 2018-11-14 17:47 ` Mike Snitzer 2018-11-14 17:47 ` Mike Snitzer 2018-11-14 18:51 ` Hannes Reinecke 2018-11-14 18:51 ` Hannes Reinecke 2018-11-14 19:26 ` Mike Snitzer 2018-11-14 19:26 ` Mike Snitzer 2018-11-15 17:46 ` [PATCH] nvme: allow ANA support to be independent of native multipathing Mike Snitzer 2018-11-15 17:46 ` Mike Snitzer 2018-11-16 7:25 ` Hannes Reinecke 2018-11-16 7:25 ` Hannes Reinecke 2018-11-16 14:01 ` Mike Snitzer 2018-11-16 14:01 ` Mike Snitzer 2018-11-16 9:14 ` [PATCH] " Christoph Hellwig 2018-11-16 9:14 ` Christoph Hellwig 2018-11-16 9:40 ` Hannes Reinecke [this message] 2018-11-16 9:40 ` Hannes Reinecke 2018-11-16 9:49 ` Christoph Hellwig 2018-11-16 9:49 ` Christoph Hellwig 2018-11-16 10:06 ` Hannes Reinecke 2018-11-16 10:06 ` Hannes Reinecke 2018-11-16 10:17 ` Christoph Hellwig 2018-11-16 10:17 ` Christoph Hellwig 2018-11-16 19:28 ` Mike Snitzer 2018-11-16 19:28 ` Mike Snitzer 2018-11-16 19:34 ` Laurence Oberman 2018-11-16 19:34 ` Laurence Oberman 2018-11-19 9:39 ` Christoph Hellwig 2018-11-19 9:39 ` Christoph Hellwig 2018-11-19 14:56 ` Mike Snitzer 2018-11-19 14:56 ` Mike Snitzer 2018-11-19 14:56 ` Mike Snitzer 2018-11-20 9:42 ` Christoph Hellwig 2018-11-20 9:42 ` Christoph Hellwig 2018-11-20 13:37 ` Mike Snitzer 2018-11-20 13:37 ` Mike Snitzer 2018-11-20 16:23 ` Christoph Hellwig 2018-11-20 16:23 ` Christoph Hellwig 2018-11-16 14:12 ` Mike Snitzer 2018-11-16 14:12 ` Mike Snitzer 2018-11-16 18:59 ` [PATCH v2] " Mike Snitzer 2018-11-16 18:59 ` Mike Snitzer 2018-11-14 7:24 ` multipath-tools: add ANA support for NVMe device Hannes Reinecke 2018-11-14 7:24 ` Hannes Reinecke 2018-11-14 15:35 ` Christoph Hellwig 2018-11-14 15:35 ` Christoph Hellwig 2018-11-14 16:16 ` Mike Snitzer 2018-11-14 16:16 ` Mike Snitzer
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=37098edd-4dea-b58f-bca6-3be9af8ec4ee@suse.de \ --to=hare@suse.de \ --cc=axboe@kernel.dk \ --cc=bmarzins@redhat.com \ --cc=chengjike.cheng@huawei.com \ --cc=christophe.varoqui@opensvc.com \ --cc=dm-devel@redhat.com \ --cc=hch@lst.de \ --cc=keith.busch@intel.com \ --cc=lijie34@huawei.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=mwilck@suse.com \ --cc=sagi@grimberg.me \ --cc=shenhong09@huawei.com \ --cc=snitzer@redhat.com \ --cc=sschremm@netapp.com \ --cc=wangzhoumengjian@huawei.com \ --cc=xose.vazquez@gmail.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.