From: Mohamed Khalfella <mkhalfella@purestorage.com>
To: Jesse Taube <jtaubepe@redhat.com>
Cc: linux-nvme@lists.infradead.org, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
Chaitanya Kulkarni <kch@nvidia.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
John Meneghini <jmeneghi@redhat.com>,
Chris Leech <cleech@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] nvmet: Add traffic based keep alive support to configfs
Date: Tue, 22 Sep 2026 15:12:01 -0700 [thread overview]
Message-ID: <20260922221201.GE2931-mkhalfella@purestorage.com> (raw)
In-Reply-To: <20260922202257.1434980-1-jtaubepe@redhat.com>
On Tue 2026-09-22 16:22:56 -0400, Jesse Taube wrote:
> Add the ability to turn on and off tbkas (traffic based keep alive
> support) via configfs. This is useful for testing and debugging.
Yep, this is indeed useful.
>
> Signed-off-by: Jesse Taube <jtaubepe@redhat.com>
> ---
> drivers/nvme/target/admin-cmd.c | 4 +++-
> drivers/nvme/target/configfs.c | 27 +++++++++++++++++++++++++++
> drivers/nvme/target/core.c | 3 ++-
> drivers/nvme/target/nvmet.h | 1 +
> 4 files changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/nvme/target/admin-cmd.c b/drivers/nvme/target/admin-cmd.c
> index 7764a3c0195c..e734e4b68784 100644
> --- a/drivers/nvme/target/admin-cmd.c
> +++ b/drivers/nvme/target/admin-cmd.c
> @@ -696,7 +696,9 @@ static void nvmet_execute_identify_ctrl(struct nvmet_req *req)
>
> /* XXX: figure out what to do about RTD3R/RTD3 */
> id->oaes = cpu_to_le32(NVMET_AEN_CFG_OPTIONAL);
> - ctratt = NVME_CTRL_ATTR_HID_128_BIT | NVME_CTRL_ATTR_TBKAS;
> + ctratt = NVME_CTRL_ATTR_HID_128_BIT;
> + if (subsys->tbkas)
> + ctratt |= NVME_CTRL_ATTR_TBKAS;
> if (nvmet_is_pci_ctrl(ctrl))
> ctratt |= NVME_CTRL_ATTR_RHII;
> id->ctratt = cpu_to_le32(ctratt);
> diff --git a/drivers/nvme/target/configfs.c b/drivers/nvme/target/configfs.c
> index 6286e38436dd..5766e594e724 100644
> --- a/drivers/nvme/target/configfs.c
> +++ b/drivers/nvme/target/configfs.c
> @@ -1369,6 +1369,32 @@ static ssize_t nvmet_subsys_attr_serial_store(struct config_item *item,
> }
> CONFIGFS_ATTR(nvmet_subsys_, attr_serial);
>
> +static ssize_t nvmet_subsys_attr_tbkas_show(struct config_item *item,
> + char *page)
> +{
> + return snprintf(page, PAGE_SIZE, "%d\n", to_subsys(item)->tbkas);
> +}
> +
> +static ssize_t nvmet_subsys_attr_tbkas_store(struct config_item *item,
> + const char *page, size_t count)
> +{
> + struct nvmet_subsys *subsys = to_subsys(item);
> + bool tbkas;
> +
> + if (subsys->subsys_discovered) {
> + pr_err("Can't set traffic based keep alive support. %d is already assigned\n",
> + subsys->tbkas);
> + return -EINVAL;
> + }
Would it be okay to fore reconnecting existing controllers when
subsys->tbkas changes? Similar to what attr_qid_max does?
I think this will make testing more flexible by avoiding need to
recreate the subsystem in order to test tkbas on/off. Also, you may
consider adding ctrl->tkbas, again just like qid_max. It will be copied
from subsys in nvmet_alloc_ctrl() under subsys->lock.
> +
> + if (kstrtobool(page, &tbkas))
> + return -EINVAL;
> +
> + subsys->tbkas = tbkas;
> + return count;
> +}
> +CONFIGFS_ATTR(nvmet_subsys_, attr_tbkas);
> +
> static ssize_t nvmet_subsys_attr_cntlid_min_show(struct config_item *item,
> char *page)
> {
> @@ -1706,6 +1732,7 @@ static struct configfs_attribute *nvmet_subsys_attrs[] = {
> &nvmet_subsys_attr_attr_qid_max,
> &nvmet_subsys_attr_attr_ieee_oui,
> &nvmet_subsys_attr_attr_firmware,
> + &nvmet_subsys_attr_attr_tbkas,
> #ifdef CONFIG_BLK_DEV_INTEGRITY
> &nvmet_subsys_attr_attr_pi_enable,
> #endif
> diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c
> index 43871a8f56ca..20aeb9624be0 100644
> --- a/drivers/nvme/target/core.c
> +++ b/drivers/nvme/target/core.c
> @@ -1227,7 +1227,7 @@ bool nvmet_req_init(struct nvmet_req *req, struct nvmet_sq *sq,
> goto fail;
> }
>
> - if (sq->ctrl)
> + if (sq->ctrl && sq->ctrl->subsys->tbkas)
> sq->ctrl->reset_tbkas = true;
If you add ctrl->tkbas, then this will be sq->ctrl->tkbas. It is
guaranteed not to change during the lifetime of the controller.
>
> return true;
> @@ -1865,6 +1865,7 @@ struct nvmet_subsys *nvmet_subsys_alloc(const char *subsysnqn,
> }
>
> subsys->ieee_oui = 0;
> + subsys->tbkas = true;
>
> subsys->firmware_rev = kstrndup(UTS_RELEASE, NVMET_FR_MAX_SIZE, GFP_KERNEL);
> if (!subsys->firmware_rev) {
> diff --git a/drivers/nvme/target/nvmet.h b/drivers/nvme/target/nvmet.h
> index dbda55895f4f..241eac4fa969 100644
> --- a/drivers/nvme/target/nvmet.h
> +++ b/drivers/nvme/target/nvmet.h
> @@ -343,6 +343,7 @@ struct nvmet_subsys {
> bool subsys_discovered;
> char *subsysnqn;
> bool pi_support;
> + bool tbkas;
>
> struct config_group group;
>
> --
> 2.55.0
>
prev parent reply other threads:[~2026-09-22 22:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 20:22 [PATCH v1] nvmet: Add traffic based keep alive support to configfs Jesse Taube
2026-09-22 22:12 ` Mohamed Khalfella [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=20260922221201.GE2931-mkhalfella@purestorage.com \
--to=mkhalfella@purestorage.com \
--cc=cleech@redhat.com \
--cc=hch@lst.de \
--cc=jmeneghi@redhat.com \
--cc=jtaubepe@redhat.com \
--cc=kch@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=martin.petersen@oracle.com \
--cc=sagi@grimberg.me \
/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.