From: Hannes Reinecke <hare@suse.de>
To: Christoph Hellwig <hch@lst.de>
Cc: Mike Snitzer <snitzer@redhat.com>,
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 11:06:32 +0100 [thread overview]
Message-ID: <bbaf4637-209c-5cfe-2749-3fcc54f7a35f@suse.de> (raw)
In-Reply-To: <20181116094947.GA19296@lst.de>
On 11/16/18 10:49 AM, Christoph Hellwig wrote:
> On Fri, Nov 16, 2018 at 10:40:40AM +0100, Hannes Reinecke wrote:
>>>> 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?
>
> I just see the next step of wanting to move ANA code into the core
> which is implied above.
Really, I couldn't care less _where_ the ANA code lives.
If the size of which is any concern we can even make it configurable of
sorts.
>>
>>> 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?
>
> "second" here means the sysfs file.
>
Ok, so would you be happy with making ANA support configurable?
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)
next prev parent reply other threads:[~2018-11-16 10:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1541657381-7452-1-git-send-email-lijie34@huawei.com>
[not found] ` <2691abf6733f791fb16b86d96446440e4aaff99f.camel@suse.com>
[not found] ` <20181112215323.GA7983@redhat.com>
[not found] ` <20181113161838.GC9827@localhost.localdomain>
2018-11-13 18:00 ` multipath-tools: add ANA support for NVMe device Mike Snitzer
2018-11-14 5:38 ` Mike Snitzer
2018-11-14 7:49 ` Hannes Reinecke
2018-11-14 10:36 ` [dm-devel] " Martin Wilck
2018-11-14 17:47 ` Mike Snitzer
2018-11-14 18:51 ` Hannes Reinecke
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-16 7:25 ` Hannes Reinecke
2018-11-16 14:01 ` Mike Snitzer
2018-11-16 9:14 ` [PATCH] " Christoph Hellwig
2018-11-16 9:40 ` Hannes Reinecke
2018-11-16 9:49 ` Christoph Hellwig
2018-11-16 10:06 ` Hannes Reinecke [this message]
2018-11-16 10:17 ` Christoph Hellwig
2018-11-16 19:28 ` Mike Snitzer
2018-11-16 19:34 ` Laurence Oberman
2018-11-19 9:39 ` Christoph Hellwig
2018-11-19 14:56 ` Mike Snitzer
2018-11-20 9:42 ` Christoph Hellwig
2018-11-20 13:37 ` Mike Snitzer
2018-11-20 16:23 ` Christoph Hellwig
2018-11-16 14:12 ` Mike Snitzer
2018-11-16 18:59 ` [PATCH v2] " 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=bbaf4637-209c-5cfe-2749-3fcc54f7a35f@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: 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).