From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f169.google.com (mail-dy1-f169.google.com [74.125.82.169]) (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 235BA22B8B6 for ; Sat, 14 Feb 2026 03:56:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771041418; cv=none; b=sXo68J67OENkxP7AcD6RCsjpmE7EiMwF5HsVK9TepQvOCt1LYFiLpu9QrxX/v8b6FiFI2InIHLBh4YAto2JCl5wG7Qn1B0JpLGDw/wbZLiQ0FrGajxWfTlz8oc0uB2vk5mjm3/IPKlLi6k88ROP9X8fAwA21xnVLhaLfai8rTks= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771041418; c=relaxed/simple; bh=OtYRpmDJXO6Czgf1iGsM1zJ7TU3qXn8C6HA5zHJgdy4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aKh4ISMD9P9O7czSwVzTdOtceYdx9iv7y61lPTUez5SfsoPE0yYgCNwgWEzP1IYYJaTq6NC4aC9uOTGf/5FFzlqHezF17uceYNZMChLT46mSJILaxoC74ipenFu4v5npQdg1j0gKQ5CieoWdyrNjYKc/7PmSfYV2Y44EiWaOJpY= 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=DJj0YH88; arc=none smtp.client-ip=74.125.82.169 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="DJj0YH88" Received: by mail-dy1-f169.google.com with SMTP id 5a478bee46e88-2b86671f87eso3058783eec.0 for ; Fri, 13 Feb 2026 19:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1771041416; x=1771646216; 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=4z7I9/cOjKpEZZ3/JySSx+yHMUVTI86sF9dh2MgV87Q=; b=DJj0YH88y7roNH7VGlZaCNZ10C0FE+oDKiTS5TqJV9ygXUwNeENw1lfGZOUobA4gZU ooINR/qb1EbDDo6F5YfUMfAilMkyeGChROwZttQ2Ks+R7/u4SKtl58vTIbK8OHL/ysn5 bF1Y6oZ06yKKM6YDOsf25ASXKu44zCT8gJ2YpMlNC94gIusTJ0VRvei/AAjhLeII4klL ei41wHbhmhLw00Efw0tAagJmeYhnKWuF5dJ4ad0JfsCE3BL/7Dx7KlOU9ASpQ3dGDAt/ 52IjJWJLi2KLyGbB7RKoXs9DlxVkdnfeim8Mm0P+sHV8gWj6OGd1l/WaJYpsZ1zVJrCy Qj7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771041416; x=1771646216; 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=4z7I9/cOjKpEZZ3/JySSx+yHMUVTI86sF9dh2MgV87Q=; b=LnlRzsfPnNoEVneeeK9ZvDrMBfUXAeeyDMRHqUZCQ4hmyn3CAlHjpAKcRHlOmfJ64C 3C6UGPgL7CHGO4osqH87m85Nf7NyzdY4oB8hrAJp91jxHAEivIO1Jbs/qi6Gu3JEH614 +cT8OGkaKVP73ligaVEQvOyyZyMOXZEL6rOjUdz/1xHVT4dd5MHo1rVyZhtoE+XoTkC9 vLnX6bZxhDuX0MkZjC26AsumKwisXA1YAJdeUbcE17G+CJC7UwDir801bIFTmSzR6WEu 2Pu06pUrmG7TNHCvnpvT2bl0FSSGbUTG9i+zyWI33HQupp/PRGDxhDLeFYNP1Ycz2LR4 wlJg== X-Forwarded-Encrypted: i=1; AJvYcCU0fnPaZE/+vSSaIdrVYrUHxUdd4+8zyEaypY57ps4ue6SJvQfo1TAAKLB0JQLNOnnNG68NPhE8MsgjxO4=@vger.kernel.org X-Gm-Message-State: AOJu0YzEzOq0gfRcmzqzG3u1k77lmIWkY00czNz2TaWbT1fZsaqov71p oofgHtX5vUy/ZTiaPg3Y8Jj86SPHekyrrPemAbZOFBaHfSGAzbWVabltj/0zPFFhZC8= X-Gm-Gg: AZuq6aLZpPddntl623vyPKyP7yZ0A5binJlFcQu4kPZ4IACq6xUtH5GOey6obxnGrRX hYR+TxvIBDo2AZsc2E69kxDBt9GNFaWknyGpr8wkrIQez37aTBTTTJtYK7u3OGH2D0fuL2WsZIA j5FDH9WRUOGLa9yitpfc7tkaXBVthKeu6Wlo3/ilWnUF0oRvwYm75dU+p4YeGfA31xFDkf+3Cwa sHOQYE3ioUrMuHuiR50DIJLN1B4xlIDflaqDLl6uaGYwsae21biVFp842Ha7fFDeUH7W60VJAt6 gEXC8TQrbY0T0z9Od4uq6R/dUrj9zbaTJuQ1i7iyW2K/LEqdOaBqtWBXDTCvHfWv/zK/m70Khri MIrM8npr7lGk5S0/3djKPShd/jUjgCgWCxdkygQYLLWReOJghXeHTqVssme2Oh/62tFH5AWesvl 7WMxwHCLY7uuNHDk1ld7gsqLs5Iphr/d7hr67X6eg5rPM= X-Received: by 2002:a05:7022:f102:b0:124:acc6:6dd1 with SMTP id a92af1059eb24-1273ae8185bmr1982067c88.46.1771041415787; Fri, 13 Feb 2026 19:56:55 -0800 (PST) Received: from medusa.lab.kspace.sh ([208.88.152.253]) by smtp.googlemail.com with UTF8SMTPSA id a92af1059eb24-12742b62455sm1018488c88.1.2026.02.13.19.56.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Feb 2026 19:56:55 -0800 (PST) Date: Fri, 13 Feb 2026 19:56:54 -0800 From: Mohamed Khalfella To: Randy Jennings Cc: Sagi Grimberg , Hannes Reinecke , Justin Tee , Naresh Gottumukkala , Paul Ely , Chaitanya Kulkarni , Christoph Hellwig , Jens Axboe , Keith Busch , Aaron Dailey , 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: <20260214035654.GC3435530-mkhalfella@purestorage.com> References: <20260130223531.2478849-1-mkhalfella@purestorage.com> <20260130223531.2478849-2-mkhalfella@purestorage.com> <59a8d510-d06d-4d35-b911-c758c184df52@suse.de> <20260203181457.GA3729-mkhalfella@purestorage.com> <35ae10c9-808a-4882-86dc-311b23c821e5@grimberg.me> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri 2026-02-13 16:42:55 -0800, Randy Jennings wrote: > On Sat, Feb 7, 2026 at 5:41 AM Sagi Grimberg wrote: > > > > > > > Precisely my point. If CQT defaults to zero no delay will be inserted, > > > but we _still_ have CCR handling. Just proving that both really are > > > independent on each other. Hence I would prefer to have two patchsets. > > > > Agreed. I think it would be cleaner to review each separately. the CCR > > can be based > > on top of the CQT patchset, for simplicity. > > > Hannes, I have some concerns about structuring the CQT patches > separate from the CCR patches. > > We are trying to fix the Ghost Write data corruption, and this has > been a long process (involving 3 modifications to the spec and a > number of proposed patch sets). We’ve already been told (explicitly > and implicitly) that CCR is the more interesting solution (a > euphemism) for solving this data corruption. I have some concern > that, if separated, the CCR patches will get accepted without the CQT > patches. > > CCR does not work in all cases, so I do not see them as independent as > you are saying here. Also, CQT is a natural time cap on the retries > needed for CCR to handle CCR retries when it cannot succeed down some > paths. When used as a time cap, CQT fits well with the CCR changes. > > I am concerned that it will be more complicated to review the CQT > changes, with at least more patches to review. True. It results in more patches to review. However, I think it is easier to see the delay added by CQT after the it has pulled pulled into separate set of patches. > > Structuring the patches with CQT first and CCR second would take care > of many of these concerns. > > Sincerely, > Randy Jennings