From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f182.google.com (mail-dy1-f182.google.com [74.125.82.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 07A96286D70 for ; Tue, 3 Feb 2026 18:14:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770142501; cv=none; b=CggmAp6oB0jOod5F0ox1hJc6b5ApHqr/Xd1z39rMciGh0TvRY5e78eMjmv/br6SpXJ7QJpJ/bRicF2A5Pyq932sb70YNvMVW4E6YtePLxB7TBuFtBdmqO0vrNE/IslVZyGWVrsPb4t2yS9+AMCInGA+VlSK5i9UdzLqpowe1A/8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770142501; c=relaxed/simple; bh=eAaKtbZSzhLQxXDfSVRC6ALug5tyIXxE2uh4dp5y7lE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=vALQ9otkyoKDbKOGXU+0AbJ4W12OYtJVPc3/RC7aLGsZs3ZBewbmdr04jLcvvVBWBCxa0A4b8sMkwc2GEfOGJH67vnpN6EQi/Brkz4lu3m4Llvgx+tAdyXdkpvj9ad8UIV4xRJ8Mauf5+zIpgGIvoPuDNhHYK15sEWVkWLIdpEk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=purestorage.com; spf=fail smtp.mailfrom=purestorage.com; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b=CRxxTQ2m; arc=none smtp.client-ip=74.125.82.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=purestorage.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=purestorage.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b="CRxxTQ2m" Received: by mail-dy1-f182.google.com with SMTP id 5a478bee46e88-2b7381d2d95so64439eec.0 for ; Tue, 03 Feb 2026 10:14:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1770142499; x=1770747299; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0vdwhwWiiYehKcYHjHdqrWTOu+VB4ebHGcBbsRbHUcE=; b=CRxxTQ2mWl/XB8Slz1lvr+C4WU7TQArTAcrDaxymFQN0Nkma3EAQcPZKgupvLbqdW9 0RIM+9Unz/qd/KYk6wQ8OqQ0cR4gSv4puIfIU2WfkcHwCnS6NWP5bh2gIXJjQoUdwFUz 0ZbRBafhw4PIl1kWdVh3SYxzwQ3MXzuNAg66Otp9UuhQMnFc1bJri+RtEkVPycbcmbu2 HEL5kJPRWAbSt4NcXED2eODZs+SQifUeyE7WuuTSIdzeIVq4l57dwlve/3/GcAqAO3yj MNhwzq2tV0ZZPCX1lYjcA7u7s1RIjyrFy2X24imZmEbg0rASWikYmLw03wfysDkWQcPm DanQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770142499; x=1770747299; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0vdwhwWiiYehKcYHjHdqrWTOu+VB4ebHGcBbsRbHUcE=; b=mjLnuWn12cavJYZQEyXICCH+MCz2fQ0QePZ2ESQfa7HDkPnoa+9L2DC998ZxYBLVbk 0jIb1HLAs5DKoOcbXhJ3FIB+ZFcZEtREEJcePaqKR0YUw+wjqrP1r2jhUoU7vXrQlBaS PcpfqYWyZgtAcODS1QDvBjYTSPG8EFad/th/Iu8l00cuE7/RyQyZKYwEH1UPaa8e0WcT iC39DjRJVrwAU1axBDWYtC72lEFMCTI5pDdkknnt0+pd1CBESxqhqj0JlNWUCS5bHxuX w7BkPu23D7BuT0H0RwXw4NTdeh4Ltz9R3x2lRK2qhHvOQGqqbbmUOjS33Axd0B/NJgfB QwYA== X-Forwarded-Encrypted: i=1; AJvYcCX3VlTPwloARgHb3T8dKmQ9PS/B1vnpspSlaJYuNNQw34an2QLD1vBf+TpyuJCo3AiodJltJaPXpmZq0jo=@vger.kernel.org X-Gm-Message-State: AOJu0YxNpaNAM7YpZC6nLergZYmoyHHnXV6DiDR7FnFJ5ckX/JDOSTEn sWPlK7z13Y3+gRwCgyCYATAWmEQdw1i8zqUWHrZW84tB8TsmCREFj4SvP/HDMw6x3qg= X-Gm-Gg: AZuq6aKSpxGkrUUBuFSv4LkQfYwjN7K1F9oVpqcHPIsJvecJV9+mD9snFjXwdJgAhaN WUfd0k/5UwBlOX0pwfeDQ7hybVI4b2TPucDaDH+bmOqiN4fw+0M/NegHwWqVyG2Cvy3mPquw7lC 5FuqSAtyuQ7RzUiqezOB5R6e26NoJHOTwTnz7HuOAXCw00IcqVbYAbkX7BtC/uDiuGU7p0hfhXx nYAk2g3pbp5+7FNInTE8UFhaAkW+iLlAHGs05okqCbrUbQBFtkMjVL/wg+GkmfhHZZ4fqkH0Kom 4iD9+Dsb73OkPuMuMu6lKJ60aK4MqJOrSwvNPKd6o7l1+GIjcQDWEFYec6Mjsi74N6ONXKdENp0 U28Cmyzw6+nboasr/RD5v0q4D04e5D9W6mK72jKjWEkXGlFvlLC2XFhg+JZjA0i/JykpVIbVggd 2y4N/AtiWIU1CuTYM0sVa1EKyxKknzV3A= X-Received: by 2002:a05:7300:b54d:b0:2a4:646c:e096 with SMTP id 5a478bee46e88-2b820a61b70mr1176725eec.0.1770142498693; Tue, 03 Feb 2026 10:14:58 -0800 (PST) Received: from medusa.lab.kspace.sh ([208.88.152.253]) by smtp.googlemail.com with UTF8SMTPSA id 5a478bee46e88-2b832e4d18fsm155355eec.13.2026.02.03.10.14.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Feb 2026 10:14:58 -0800 (PST) Date: Tue, 3 Feb 2026 10:14:57 -0800 From: Mohamed Khalfella To: Hannes Reinecke Cc: Justin Tee , Naresh Gottumukkala , Paul Ely , Chaitanya Kulkarni , Christoph Hellwig , Jens Axboe , Keith Busch , Sagi Grimberg , Aaron Dailey , Randy Jennings , Dhaval Giani , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 01/14] nvmet: Rapid Path Failure Recovery set controller identify fields Message-ID: <20260203181457.GA3729-mkhalfella@purestorage.com> References: <20260130223531.2478849-1-mkhalfella@purestorage.com> <20260130223531.2478849-2-mkhalfella@purestorage.com> <59a8d510-d06d-4d35-b911-c758c184df52@suse.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59a8d510-d06d-4d35-b911-c758c184df52@suse.de> On Tue 2026-02-03 04:03:22 +0100, Hannes Reinecke wrote: > On 1/30/26 23:34, Mohamed Khalfella wrote: > > TP8028 Rapid Path Failure Recovery defined new fields in controller > > identify response. The newly defined fields are: > > > > - CIU (Controller Instance UNIQUIFIER): is an 8bit non-zero value that > > is assigned a random value when controller first created. The value is > > expected to be incremented when RDY bit in CSTS register is asserted > > - CIRN (Controller Instance Random Number): is 64bit random value that > > gets generated when controller is crated. CIRN is regenerated everytime > > RDY bit is CSTS register is asserted. > > - CCRL (Cross-Controller Reset Limit) is an 8bit value that defines the > > maximum number of in-progress controller reset operations. CCRL is > > hardcoded to 4 as recommended by TP8028. > > > > TP4129 KATO Corrections and Clarifications defined CQT (Command Quiesce > > Time) which is used along with KATO (Keep Alive Timeout) to set an upper > > time limit for attempting Cross-Controller Recovery. For NVME subsystem > > CQT is set to 0 by default to keep the current behavior. The value can > > be set from configfs if needed. > > > > Make the new fields available for IO controllers only since TP8028 is > > not very useful for discovery controllers. > > > > Signed-off-by: Mohamed Khalfella > > --- > > drivers/nvme/target/admin-cmd.c | 6 ++++++ > > drivers/nvme/target/configfs.c | 31 +++++++++++++++++++++++++++++++ > > drivers/nvme/target/core.c | 12 ++++++++++++ > > drivers/nvme/target/nvmet.h | 4 ++++ > > include/linux/nvme.h | 15 ++++++++++++--- > > 5 files changed, 65 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/nvme/target/admin-cmd.c b/drivers/nvme/target/admin-cmd.c > > index 3da31bb1183e..ade1145df72d 100644 > > --- a/drivers/nvme/target/admin-cmd.c > > +++ b/drivers/nvme/target/admin-cmd.c > > @@ -696,6 +696,12 @@ static void nvmet_execute_identify_ctrl(struct nvmet_req *req) > > > > id->cntlid = cpu_to_le16(ctrl->cntlid); > > id->ver = cpu_to_le32(ctrl->subsys->ver); > > + if (!nvmet_is_disc_subsys(ctrl->subsys)) { > > + id->cqt = cpu_to_le16(ctrl->cqt); > > + id->ciu = ctrl->ciu; > > + id->cirn = cpu_to_le64(ctrl->cirn); > > + id->ccrl = NVMF_CCR_LIMIT; > > + } > > > > /* XXX: figure out what to do about RTD3R/RTD3 */ > > id->oaes = cpu_to_le32(NVMET_AEN_CFG_OPTIONAL); > > diff --git a/drivers/nvme/target/configfs.c b/drivers/nvme/target/configfs.c > > index e44ef69dffc2..035f6e75a818 100644 > > --- a/drivers/nvme/target/configfs.c > > +++ b/drivers/nvme/target/configfs.c > > @@ -1636,6 +1636,36 @@ static ssize_t nvmet_subsys_attr_pi_enable_store(struct config_item *item, > > CONFIGFS_ATTR(nvmet_subsys_, attr_pi_enable); > > #endif > > > > +static ssize_t nvmet_subsys_attr_cqt_show(struct config_item *item, > > + char *page) > > +{ > > + return snprintf(page, PAGE_SIZE, "%u\n", to_subsys(item)->cqt); > > +} > > + > > +static ssize_t nvmet_subsys_attr_cqt_store(struct config_item *item, > > + const char *page, size_t cnt) > > +{ > > + struct nvmet_subsys *subsys = to_subsys(item); > > + struct nvmet_ctrl *ctrl; > > + u16 cqt; > > + > > + if (sscanf(page, "%hu\n", &cqt) != 1) > > + return -EINVAL; > > + > > + down_write(&nvmet_config_sem); > > + if (subsys->cqt == cqt) > > + goto out; > > + > > + subsys->cqt = cqt; > > + /* Force reconnect */ > > + list_for_each_entry(ctrl, &subsys->ctrls, subsys_entry) > > + ctrl->ops->delete_ctrl(ctrl); > > +out: > > + up_write(&nvmet_config_sem); > > + return cnt; > > +} > > +CONFIGFS_ATTR(nvmet_subsys_, attr_cqt); > > + > > static ssize_t nvmet_subsys_attr_qid_max_show(struct config_item *item, > > char *page) > > { > > @@ -1676,6 +1706,7 @@ static struct configfs_attribute *nvmet_subsys_attrs[] = { > > &nvmet_subsys_attr_attr_vendor_id, > > &nvmet_subsys_attr_attr_subsys_vendor_id, > > &nvmet_subsys_attr_attr_model, > > + &nvmet_subsys_attr_attr_cqt, > > &nvmet_subsys_attr_attr_qid_max, > > &nvmet_subsys_attr_attr_ieee_oui, > > &nvmet_subsys_attr_attr_firmware, > > I do think that TP8028 (ie the CQT defintions) are somewhat independent > on CCR. So I'm not sure if they should be integrated in this patchset; > personally I would prefer to have it moved to another patchset. Agreed that CQT is not directly related to CCR from the target perspective. But there is a relationship when it comes to how the initiator uses CQT to calculate the time budget for CCR. As you know on the host side if CCR fails and CQT is supported the requests needs to be held for certain amount of time before they are retried. So CQT value is needed and that I why I included it in this patchset. > > > diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c > > index cc88e5a28c8a..0d2a1206e08f 100644 > > --- a/drivers/nvme/target/core.c > > +++ b/drivers/nvme/target/core.c > > @@ -1393,6 +1393,10 @@ static void nvmet_start_ctrl(struct nvmet_ctrl *ctrl) > > return; > > } > > > > + if (!nvmet_is_disc_subsys(ctrl->subsys)) { > > + ctrl->ciu = ((u8)(ctrl->ciu + 1)) ? : 1; > > + ctrl->cirn = get_random_u64(); > > + } > > ctrl->csts = NVME_CSTS_RDY; > > > > /* > > @@ -1661,6 +1665,12 @@ struct nvmet_ctrl *nvmet_alloc_ctrl(struct nvmet_alloc_ctrl_args *args) > > } > > ctrl->cntlid = ret; > > > > + if (!nvmet_is_disc_subsys(ctrl->subsys)) { > > + ctrl->cqt = subsys->cqt; > > + ctrl->ciu = get_random_u8() ? : 1; > > + ctrl->cirn = get_random_u64(); > > + } > > + > > /* > > * Discovery controllers may use some arbitrary high value > > * in order to cleanup stale discovery sessions > > @@ -1853,10 +1863,12 @@ struct nvmet_subsys *nvmet_subsys_alloc(const char *subsysnqn, > > > > switch (type) { > > case NVME_NQN_NVME: > > + subsys->cqt = NVMF_CQT_MS; > > subsys->max_qid = NVMET_NR_QUEUES; > > break; > > And I would not set the CQT default here. > Thing is, implementing CQT to the letter would inflict a CQT delay > during failover for _every_ installation, thereby resulting in a > regression to previous implementations where we would fail over > with _no_ delay. > So again, we should make it a different patchset. CQT defaults to 0 to avoid introducing surprise delay. The initiator will skip holding requests if it sees CQT set to 0.