From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f181.google.com (mail-dy1-f181.google.com [74.125.82.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 5657D37105D for ; Tue, 17 Feb 2026 17:58:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771351133; cv=none; b=YNArW5mzzf0E/nrMdtljQ9vRSRIFBpA8w1xaTJocimYG0F/UEwWvpyfWoiUsQzU0abO81B2rCX8v7O2w6V3BSlUL0hwW/50dyyHzinL+PkTJglpSWKDgHVckzvf3XfVegcBZRJS47uBvyh0EHEg5/HcHUua0OUp+eJO7rwhZRQ0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771351133; c=relaxed/simple; bh=2ijkiIvA6q5ZshZy2GNT84o//YWQCEUs18svzj0PrMI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=t7Y5nD5NmvNn4gDKQMycXpFsnW1NgwSjKxLIpykdB1uflDEyY6m4Z1EhHV5QmnL9vgBQMBBpgJ0o/2PK0hhkyHL4t43PFu6SOJkAnORx17CbfsCD5h/xcmc2dw9fl6DrQw5EKfGA/2iBKH3iaWo+EqXr6rTpFZNfvGlGqXbQb3I= 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=GPpjqYAw; arc=none smtp.client-ip=74.125.82.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="GPpjqYAw" Received: by mail-dy1-f181.google.com with SMTP id 5a478bee46e88-2b785801c93so11243645eec.0 for ; Tue, 17 Feb 2026 09:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1771351130; x=1771955930; 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=4dyoQALK3UpZsKvQZapV/kBgywQgWDNhj/strtjOdpc=; b=GPpjqYAwCUGvd6rCZxoxRqRWtAT3rlxVK8u9GwKRb9xGWUxlbZNQfcOf3R8WI3q+po K/mH2notFbSPLF248TWDNJiDvhQXgtwbN1PHPQB+3uVRngHedsKkfS1FscYUPVa8c+Pm qY0onP9MDHc+mrh+QDleQYu6ai4WoADAkKpX6LTX7hR7LTQfeCPv/o1uFnAQQfvoljsz +RwMnmgs0M7u3F2TJPJ3ZpvSrCtGmc/Cq+km6hNU9yXhdGOm/KsUX6zyGrnNp+WDWjPD UAFmvd22I/2cRFU/1369SqB+X3beW8TOHZZGi22c6Zq2bmnq4fPv/WSAi2oWy0eh8j0t 78TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771351130; x=1771955930; 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=4dyoQALK3UpZsKvQZapV/kBgywQgWDNhj/strtjOdpc=; b=q+BfXxISWwqkUVEj+Me5GdzeRiqyN18id7J9FEB988wPwOwFRrmYFHrPvj+nInwZLy /t7+3pVr82F2qU/KRMl471eHoOa3MmWheH2Poi7yFC4DGPVq8YUfmghcUtc6HvdWbUc5 yBe7eQ5BrwrIkCH4K6AtUIhhTiE0QE56vPLPbGuKy4ST3gKZEmntxxeN3LEs1PSdymTz bR4tOa1ZELSl68LyPSPZjXF2onm9Ev/26heJ9ODoUvxlUKxPsOxAfBTmgJDbbpMvAzcN QEPdi3gn9FbDb78BK1wQ456ATIkzrrcpoEWHIT++f0/7fGLnj/au5QW2mkjBMWgIV0UG HVWw== X-Forwarded-Encrypted: i=1; AJvYcCXrgVXL3oMAObnWX17yr/QTQ3rnra5NZ5VNIO5IWMBtYwkjdDNM1tFU+nNJ7A2/lfEx1A83Ay4J44xbHCw=@vger.kernel.org X-Gm-Message-State: AOJu0Yxk5iWBWfinRIPs6FWOf7FD6LLvL0glaruQxyReyOU5S8BediRN fCPReoLqcev67GzE+llfYmrGZIUcANLKCSOSlShE4pyy6SXzP6Sh3+PeLxTXKvjXvMY= X-Gm-Gg: AZuq6aIsqRxe7ClvJt75APUh1tg7OgQIqL94nS0Vh9BgFqY8WHn8iLBzGhuh1+6HlHc OAh3IKVrHpvniJd/dN+kuq9zXFpxDi85glyc3hj1fPC9+EACBztwpeGLK18Y3BNi4Gb8dAddxhG b83GmLYx0/tidiaRCclI+AQy0FQpwZ67V9drfk7iDFJ/KAvQnojJ/HigcKeGAl2TiODzUH0i+a1 gO+HTWojvmNlMKlBEiGIt6nFYfsuXwJduHmrAD3TqtL2h8piNKOlIWdEJqgqhwgAmhLUvrUmc03 tAYUZg5P7xE3QXAvP4yPozpflGSQMIrU4ZI1fBqvon/T3jgj82xnEAArEc1LC2VXJn7djlnrTgf jDsnobmKQwNtXg15M45RpVsCocg+NGngYqaa5eLB65lyOZmBQ/IL5UqJcq5ZD6ZKNNO0+Sv6uoG K+p15XAQuWryJHJS81elxXOANhGxHvfuVB7p9v1kHEhZo= X-Received: by 2002:a05:7301:4083:b0:2b8:6b32:1cf1 with SMTP id 5a478bee46e88-2bac97c5053mr5778400eec.29.1771351130179; Tue, 17 Feb 2026 09:58:50 -0800 (PST) Received: from medusa.lab.kspace.sh ([208.88.152.253]) by smtp.googlemail.com with UTF8SMTPSA id 5a478bee46e88-2bacb6782e5sm14878843eec.29.2026.02.17.09.58.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Feb 2026 09:58:49 -0800 (PST) Date: Tue, 17 Feb 2026 09:58:48 -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 19/21] nvme-tcp: Extend FENCING state per TP4129 on CCR failure Message-ID: <20260217175848.GD3435530-mkhalfella@purestorage.com> References: <20260214042753.4073668-1-mkhalfella@purestorage.com> <20260214042753.4073668-20-mkhalfella@purestorage.com> <7fcdb6bb-34b4-4b73-afce-75c423f8400b@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: <7fcdb6bb-34b4-4b73-afce-75c423f8400b@suse.de> On Mon 2026-02-16 13:56:10 +0100, Hannes Reinecke wrote: > On 2/14/26 05:25, Mohamed Khalfella wrote: > > If CCR operations fail and CQT is supported, we must defer the retry of > > inflight requests per TP4129. Update ctrl->fencing_work to schedule > > ctrl->fenced_work, effectively extending the FENCING state. This delay > > ensures that inflight requests are held until it is safe for them to be > > retired. > > > > Signed-off-by: Mohamed Khalfella > > --- > > drivers/nvme/host/tcp.c | 39 +++++++++++++++++++++++++++++++++++---- > > 1 file changed, 35 insertions(+), 4 deletions(-) > > > Can't you merge / integrate this into the nvme_fence_ctrl() routine? ctrl->fencing_work and ctrl->fenced_work are in transport specific controller, struct nvme_tcp_ctrl in this case. There is no easy way to access these members from nvme_fence_ctrl(). One option to go around that is to move them into struct nvme_ctrl. But we call error recovery after a controller is fenced, and error recovery is implemented in transport specific way. That is why the delay is implemented/repeated for every transport. > The previous patch already extended the timeout to cover for CQT, so > we can just wait for the timeout if CCR failed, no? Following on the point above. One change can be done is to reset the controller after fencing finishes instead of using error recovery. This way everything lives in core.c. But I have not tested that. Do you think this is better than what has been implemented now?