All of lore.kernel.org
 help / color / mirror / Atom feed
From: snitzer@redhat.com (Mike Snitzer)
Subject: multipath-tools: add ANA support for NVMe device
Date: Mon, 12 Nov 2018 16:53:23 -0500	[thread overview]
Message-ID: <20181112215323.GA7983@redhat.com> (raw)
In-Reply-To: <2691abf6733f791fb16b86d96446440e4aaff99f.camel@suse.com>

On Mon, Nov 12 2018 at 11:23am -0500,
Martin Wilck <mwilck@suse.com> wrote:

> Hello Lijie,
> 
> On Thu, 2018-11-08@14:09 +0800, lijie wrote:
> > Add support for Asynchronous Namespace Access as specified in NVMe
> > 1.3
> > TP 4004. The states are updated through reading the ANA log page.
> > 
> > By default, the native nvme multipath takes over the nvme device.
> > We can pass a false to the parameter 'multipath' of the nvme-core.ko
> > module,when we want to use multipath-tools.
> 
> Thank you for the patch. It looks quite good to me. I've tested it with
> a Linux target and found no problems so far.
> 
> I have a few questions and comments inline below.
> 
> I suggest you also have a look at detect_prio(); it seems to make sense
> to use the ana prioritizer for NVMe paths automatically if ANA is
> supported (with your patch, "detect_prio no" and "prio ana" have to be
> configured explicitly). But that can be done in a later patch.

I (and others) think it makes sense to at least triple check with the
NVMe developers (now cc'd) to see if we could get agreement on the nvme
driver providing the ANA state via sysfs (when modparam
nvme_core.multipath=N is set), like Hannes proposed here:
http://lists.infradead.org/pipermail/linux-nvme/2018-November/020765.html

Then the userspace multipath-tools ANA support could just read sysfs
rather than reinvent harvesting the ANA state via ioctl.

But if we continue to hit a wall on that type of sharing of the nvme
driver's state then I'm fine with reinventing ANA state inquiry and
tracking like has been proposed here.

Mike

p.s. thanks for your review Martin, we really need to determine the way
forward for full multipath-tools support of NVMe with ANA.

WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com>
To: Martin Wilck <mwilck@suse.com>
Cc: linux-nvme@lists.infradead.org, lijie <lijie34@huawei.com>,
	xose.vazquez@gmail.com, chengjike.cheng@huawei.com,
	shenhong09@huawei.com, dm-devel@redhat.com,
	wangzhoumengjian@huawei.com, sschremm@netapp.com
Subject: Re: multipath-tools: add ANA support for NVMe device
Date: Mon, 12 Nov 2018 16:53:23 -0500	[thread overview]
Message-ID: <20181112215323.GA7983@redhat.com> (raw)
In-Reply-To: <2691abf6733f791fb16b86d96446440e4aaff99f.camel@suse.com>

On Mon, Nov 12 2018 at 11:23am -0500,
Martin Wilck <mwilck@suse.com> wrote:

> Hello Lijie,
> 
> On Thu, 2018-11-08 at 14:09 +0800, lijie wrote:
> > Add support for Asynchronous Namespace Access as specified in NVMe
> > 1.3
> > TP 4004. The states are updated through reading the ANA log page.
> > 
> > By default, the native nvme multipath takes over the nvme device.
> > We can pass a false to the parameter 'multipath' of the nvme-core.ko
> > module,when we want to use multipath-tools.
> 
> Thank you for the patch. It looks quite good to me. I've tested it with
> a Linux target and found no problems so far.
> 
> I have a few questions and comments inline below.
> 
> I suggest you also have a look at detect_prio(); it seems to make sense
> to use the ana prioritizer for NVMe paths automatically if ANA is
> supported (with your patch, "detect_prio no" and "prio ana" have to be
> configured explicitly). But that can be done in a later patch.

I (and others) think it makes sense to at least triple check with the
NVMe developers (now cc'd) to see if we could get agreement on the nvme
driver providing the ANA state via sysfs (when modparam
nvme_core.multipath=N is set), like Hannes proposed here:
http://lists.infradead.org/pipermail/linux-nvme/2018-November/020765.html

Then the userspace multipath-tools ANA support could just read sysfs
rather than reinvent harvesting the ANA state via ioctl.

But if we continue to hit a wall on that type of sharing of the nvme
driver's state then I'm fine with reinventing ANA state inquiry and
tracking like has been proposed here.

Mike

p.s. thanks for your review Martin, we really need to determine the way
forward for full multipath-tools support of NVMe with ANA.

  reply	other threads:[~2018-11-12 21:53 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 [this message]
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
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=20181112215323.GA7983@redhat.com \
    --to=snitzer@redhat.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 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.