From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (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 58BD82D780C for ; Mon, 16 Feb 2026 18:45:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771267519; cv=none; b=erwCS3axDMd3iMxfObQE9ttdUrCtEtXExs4+qhz3/d6Fv92XGRLGMUQlwH8w+BdVnMKfFACf+dyp024VDa4GgCcbWy7ysX0SqOeX3TLigjszzEBjajSYoWcN7cI3s769vxTfNWWxSHhvkVgqj2+YgDMqkj4lHor3emJWqs5NZ4g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771267519; c=relaxed/simple; bh=2kOgjqsnOvsXy641jhEoRtfPNhLnnIjGLV+Yxfg8tgk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lq10+AAzPeBYxoHVyfoEd4Zg0KMIdQ0Q83CNtWeNrNzp9GcbhdpJHxoIpzFyYFy8ejQLPYKEcq5C/WQEgHDeenqGCJwqvBAsLyrUMHWXQ9NnTnkYYf/NBTZs5tDUQRjb8h6GcazPgTBuO7IPVcIMbdFr+JDQc5rs+1xxxzHZo1Y= 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=MAchpIKf; arc=none smtp.client-ip=209.85.210.181 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="MAchpIKf" Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-824abe734afso2134155b3a.0 for ; Mon, 16 Feb 2026 10:45:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1771267518; x=1771872318; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=OG0qAA5xbW3Ibn5X08VvAyN8MqMrXIePKScxqFmmU8A=; b=MAchpIKfZyU6lk9Kc0clAOpmqE/4j/z53sAM4yFEniGnJDEMqf4ImH3JRPxReZENv8 w6jczMml5o5LccSUKvQdd2MY6kPJ+WhDv3n/rWx69DZORXz1/cxXJmNJ2VXrgrawG37z 4YOPoJu87k5AfmKOIo1N0/IGWF4q8MWgWxXG6sai2VJo5Xtx6AWgnVmoNQBKXnMlfQWJ OMbNZSWwQ6pTkTEw9jeZp4g4oE95wJ0jmMcXlbj10v+yscM45Em9IFMFlPk1qju7AoWf fHNLuYAamnG/EjqtsxR4+pXJaHZJ8RULWja8e7Rs2SMc/JYWu2ShddW9sdLtWcOaTbpw jfAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771267518; x=1771872318; h=in-reply-to:content-transfer-encoding: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=OG0qAA5xbW3Ibn5X08VvAyN8MqMrXIePKScxqFmmU8A=; b=OlPQXhcq7n6PlCYEW9iw2yyjwvxaasEcC3re5yFsRVUckm3O8EA2QWwkmT6iGnAlAW 018/RoKkeDzsA4vVKsmYukVJCD3AoC9VLo7/FJV0KK7O8YnE2l6pi0Hxz0vTEBafSdaV krO0Cy+bQK5+xvCQG09w63cj3YhoWspyD0fg1yGXZ5AOAwuDiNeEEK/etCIY8asV6v65 Ok1ZpCbXHR9Q20hhYNM0oKaQW3ZGjqNwoefgRikUrssGSdDVLj/D413o0MeSUS59x2lQ RMmYD90zMTzW9nQ4ClbRQyYonvcwTqfFIlRMp4rNYIHODrC9SWDU6hfW7aKQFF/Y2E6n poJA== X-Forwarded-Encrypted: i=1; AJvYcCXIkDz/56yO1v+WyZdkRCfVWZu6hA1zSRn7YbokdetOdTsjN/O8OJNTs7n8LgDJcwmAM9jEF37Rz0VCb2E=@vger.kernel.org X-Gm-Message-State: AOJu0YwA8sAyfyqQCx1L2BbsriQStFzsPTRkj4K5x2eO082kWyFR4+Vr waLfXDokyRoezTl+OhjeKN4iw8zWVfRieGWeNlSKoA1snjWDztiNXSi1keXub/PE8RM= X-Gm-Gg: AZuq6aI0NHLG9qPLQHu5xTrsm1zl6bPFtWoHYvUbVXE0G40rxW+lUSgsUPtDz5BdVWn MwIReDWVM5UHMQcJLwWeHuKiiaKlHCSfrJP1kTpvuW0BCFuKr9yeEnq3Z9zxMytchefMxbrKM1/ LanQBQ9aQZtctqleFTGGGlwNa5eNd/L+lgNwasEGfwrgEifLeKdQ7nVWlWUtw9Wu/WuyI59auZC rJc8G2utdhPw0j8OCZarL7QUPaUrqqWXMtku5ZJYAJeDYQGqhcV4ZnEAHOz1xfxs5VTFagSO6j6 UNdJGhkDBfNid+2g4NznmeIbcI0nxN6J7DoYBWekUDidNWMpiuLSKRP8bOkcKPd820R+7UonAeX qmSHImAyXDLapJGwkU8+YR/i2nhO5HJUegQhZjsYAoGSB6dpoHaPfUrOE+RVJwS3BfRI+NYXP5B ps2iW2NH69v5QbhZQy/A3kQMPMfBI= X-Received: by 2002:a05:6a00:178c:b0:81f:4999:ae46 with SMTP id d2e1a72fcca58-824d961c463mr7191647b3a.48.1771267517461; Mon, 16 Feb 2026 10:45:17 -0800 (PST) Received: from medusa.lab.kspace.sh ([2601:640:8202:6fb0::68dd]) by smtp.googlemail.com with UTF8SMTPSA id d2e1a72fcca58-824c6b9528esm10424523b3a.48.2026.02.16.10.45.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 10:45:16 -0800 (PST) Date: Mon, 16 Feb 2026 10:45:15 -0800 From: Mohamed Khalfella To: Hannes Reinecke Cc: Justin Tee , Naresh Gottumukkala , Paul Ely , Chaitanya Kulkarni , Christoph Hellwig , Jens Axboe , Keith Busch , Sagi Grimberg , James Smart , Aaron Dailey , Randy Jennings , Dhaval Giani , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 18/21] nvme: Update CCR completion wait timeout to consider CQT Message-ID: <20260216184515.GH2392949-mkhalfella@purestorage.com> References: <20260214042753.4073668-1-mkhalfella@purestorage.com> <20260214042753.4073668-19-mkhalfella@purestorage.com> <9d6cf4f9-37d8-4704-bcc1-0b849ad28955@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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9d6cf4f9-37d8-4704-bcc1-0b849ad28955@suse.de> On Mon 2026-02-16 13:54:18 +0100, Hannes Reinecke wrote: > On 2/14/26 05:25, Mohamed Khalfella wrote: > > TP8028 Rapid Path Failure Recovery does not define how much time the > > host should wait for CCR operation to complete. It is reasonable to > > assume that CCR operation can take up to ctrl->cqt. Update wait time for > > CCR operation to be max(ctrl->cqt, ctrl->kato). > > > > Signed-off-by: Mohamed Khalfella > > --- > > drivers/nvme/host/core.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c > > index 0680d05900c1..ff479c0263ab 100644 > > --- a/drivers/nvme/host/core.c > > +++ b/drivers/nvme/host/core.c > > @@ -631,7 +631,7 @@ static int nvme_issue_wait_ccr(struct nvme_ctrl *sctrl, struct nvme_ctrl *ictrl) > > if (result & 0x01) /* Immediate Reset Successful */ > > goto out; > > > > - tmo = secs_to_jiffies(ictrl->kato); > > + tmo = msecs_to_jiffies(max(ictrl->cqt, ictrl->kato * 1000)); > > if (!wait_for_completion_timeout(&ccr.complete, tmo)) { > > ret = -ETIMEDOUT; > > goto out; > > That is not my understanding. I was under the impression that CQT is the > _additional_ time a controller requires to clear out outstanding > commands once it detected a loss of communication (ie _after_ KATO). > Which would mean we have to wait for up to > (ctrl->kato * 1000) + ctrl->cqt. At this point the source controller knows about communication loss. We do not need kato wait. In theory we should just wait for CQT. max(cqt, kato) is a conservative guess I made. > > Cheers, > > Hannes > -- > Dr. Hannes Reinecke Kernel Storage Architect > hare@suse.de +49 911 74053 688 > SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg > HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich