From: hch@lst.de (Christoph Hellwig)
Subject: [PATCH v1 0/5] Fix keep-alive mechanism for fabrics
Date: Fri, 13 Apr 2018 19:06:24 +0200 [thread overview]
Message-ID: <20180413170624.GC23178@lst.de> (raw)
In-Reply-To: <1523380689-17151-1-git-send-email-maxg@mellanox.com>
On Tue, Apr 10, 2018@08:18:04PM +0300, Max Gurtovoy wrote:
> I've noticed that there is no clear definition in the NVMe spec
> regarding the keep-alive mechanism association. IMO, it should be
> a property of the admin queue and should be triggered as soon as
> the admin queue configured successfuly.
It is a property of the controller, sent over the admin queue.
I'm not sure what else it could be, but if things are confusing
please reach out to the technical working group.
Note that we can only send NVMe command (rather than Fabrics commands)
when the controller is enabled. Based on that I think that we need
to fix keep alive, but in a different way than in this series.
So instead of starting keep alive in nvme_start_ctrl we should
start in nvme_enable_ctrl, and similar on the stop side with
disable/shutdown. On the target side we can also only start to
expect a a keep-alive once the controller has been enabled,
and need to stop expecting one once the controller has been disabled.
prev parent reply other threads:[~2018-04-13 17:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-10 17:18 [PATCH v1 0/5] Fix keep-alive mechanism for fabrics Max Gurtovoy
2018-04-10 17:18 ` [PATCH v1 1/5] Revert "nvme: unexport nvme_start_keep_alive" Max Gurtovoy
2018-04-10 17:18 ` [PATCH v1 2/5] nvme: remove association between ctrl and keep-alive Max Gurtovoy
2018-04-13 17:01 ` Christoph Hellwig
2018-04-10 17:18 ` [PATCH v1 3/5] nvme-rdma: add keep-alive mechanism as admin_q property Max Gurtovoy
2018-04-10 17:18 ` [PATCH v1 4/5] nvme-fc: " Max Gurtovoy
2018-04-10 17:18 ` [PATCH 5/5] nvme-loop: " Max Gurtovoy
2018-04-11 13:04 ` [PATCH v1 0/5] Fix keep-alive mechanism for fabrics Sagi Grimberg
2018-04-11 13:38 ` Max Gurtovoy
2018-04-11 14:07 ` Sagi Grimberg
2018-04-11 14:40 ` Max Gurtovoy
2018-04-11 16:48 ` James Smart
2018-04-12 8:49 ` Max Gurtovoy
2018-04-12 12:34 ` Sagi Grimberg
2018-04-12 17:28 ` James Smart
2018-04-12 12:29 ` Sagi Grimberg
2018-04-12 13:32 ` Max Gurtovoy
2018-04-12 15:17 ` Sagi Grimberg
2018-04-12 16:43 ` Max Gurtovoy
2018-04-12 12:14 ` Sagi Grimberg
2018-04-12 12:18 ` Max Gurtovoy
2018-04-12 12:31 ` Sagi Grimberg
2018-04-13 17:06 ` Christoph Hellwig [this message]
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=20180413170624.GC23178@lst.de \
--to=hch@lst.de \
/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.