All of lore.kernel.org
 help / color / mirror / Atom feed
From: james.smart@broadcom.com (James Smart)
Subject: [PATCH v1 0/5] Fix keep-alive mechanism for fabrics
Date: Thu, 12 Apr 2018 10:28:53 -0700	[thread overview]
Message-ID: <5a0754d5-49fc-abcb-f6d4-6770cad81271@broadcom.com> (raw)
In-Reply-To: <8607cd8d-a0bd-ac88-7923-2473970e587d@grimberg.me>

On 4/12/2018 5:34 AM, Sagi Grimberg wrote:
>
>> At least I see that you agree to start keep-alive timer before 
>> creating the IO queues so that's a progress :).
>> The fact that I didn't put it in nvme_enable_ctrl is because the FC 
>> code never calls nvme_disable_ctrl (and there we probably should stop 
>> the timer).
>> I'm trying to solve an issue without changing the whole design of the 
>> FC implementation. We can do it incrementaly.
>
> Please don't touch any of the transport drivers for any of this, its the
> wrong place to handle keep alive.

The reason FC doesn't call nvme_disable_ctrl() is because I don't 
believe it has much value. It's at best a "good citizen" thing that can 
encounter more problems than it's worth.? All that disable does is 
perform a pseudo reg write (property_set) to disable the controller. But 
to perform that write requires the link-side nvmeof association to not 
be failed/in error, the admin connection valid, the controller not 
failed in any way (may already be due to the error) and able to send a 
response back. In almost all cases other than an admin-requested reset, 
those things aren't necessarily valid.? So calling it, and having it 
wait for a completion isn't a great idea imho.

Thus the use jumping to nvme_stop_ctrl() instead. It is the real 
function that disables io and stops work against the controller until a 
new association can get in place.? So I agree with where the stop KA is 
now - in nvme_stop_ctrl().


>
>>>
>>> I strongly support Sagi's statements on trying to keep the KA 
>>> start/stop in common code rather than sprinkling it around. I agree 
>>> with the current placement of the stop code in nvme_stop_ctrl().?? 
>>> The stop ctrl should always be called prior to the admin queue being 
>>> torn down in the transport (as part of kicking off the reset of the 
>>> controller).
>>
>> If we'll add KA start to nvme_enable_ctrl then the KA stop should be 
>> added to nvme_disable_ctrl. We should be symmetric.
>
> Not a must. even after the controller is disabled we want to
> have a keep alive to it as we would need to enable it again at
> some point.

As indicate above - no - don't move it.

-- james

  reply	other threads:[~2018-04-12 17:28 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 [this message]
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

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=5a0754d5-49fc-abcb-f6d4-6770cad81271@broadcom.com \
    --to=james.smart@broadcom.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.