From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CDF512E11D2 for ; Mon, 23 Mar 2026 18:37:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774291075; cv=none; b=Jfn3UkEgWiGwhqGlOM2fklTVwzczTFhssGFUqkvN3kJP+kwBiAMmF7RwDFU90c6AvNkrLHPMqMy2WV3G201RBqwZqcuF2rJ/tGc6KWwcj1G7atQ0lViSK31gnno/gCZatkIHV9WaokkYiHnw0A++yQBmWb9bF6N0hAblCVcRpGo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774291075; c=relaxed/simple; bh=9cWlpHllNXUZoJ7LY2GMkPMHETTroz/3ii4+41Mehmo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aqclNPTEtR4BNFiunVyAYuBA6j9XFmnTITwxXS9O8NYtoM2J9El1gtwMNpspy+KCqE6yIrgvA2Bnq+jwU6PbdD1CWU5W1an/G9K8GK1D9S8YsEOffjIV5uhghT/krOSuusbdng+qUiJhLh94gg36JSwfRRAF9NhYMJRQzYUPo+E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pckru7Ua; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pckru7Ua" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E849C4CEF7; Mon, 23 Mar 2026 18:37:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774291075; bh=9cWlpHllNXUZoJ7LY2GMkPMHETTroz/3ii4+41Mehmo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pckru7UaNEpGLmZ0N8YZLOgopPVNZAZYGBqlVQ1uv5M0q6hfEWvcea+fG5cQoVlb9 nzYRhMgm/Bi98XcK4NEurlsg8bdU5uWjwz186WBErbITfkVYbS/fNH2G5bkakHBw0X wYdkld2M5umHVbhZmahbhwt7div6zEOTCxZzGGa+M1XHFhAGqAvVoPvaCOlUNIODfG bAa0T1OaDqtKJkVf8btm/taUNj3IW2QfNbuu9Tuirw65LWjnjk5zy9UG6qgM++87LD +ycBs2Kr69wL5QT1e8S7Qsi3KyEgfrhcnvbR23ybW/3GdZ5vNdpiNOgK+NOPmTa5v3 DoOhazik86Njg== Date: Mon, 23 Mar 2026 12:37:53 -0600 From: Keith Busch To: Caleb Sander Mateos Cc: Jens Axboe , Christoph Hellwig , Sagi Grimberg , Chaitanya Kulkarni , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/8] nvme: set discard_granularity from NPDG/NPDA Message-ID: References: <20260227202354.1012322-1-csander@purestorage.com> 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 Mon, Mar 23, 2026 at 08:29:25AM -0700, Caleb Sander Mateos wrote: > On Mon, Mar 2, 2026 at 10:54 AM Keith Busch wrote: > > > > On Fri, Feb 27, 2026 at 01:23:45PM -0700, Caleb Sander Mateos wrote: > > > NVMe block devices always report the logical block size for the > > > discard_granularity queue limit. However, more accurate values may be > > > available in the NPDG/NPDA fields of the Identify Namespace structure or > > > the NPDGL/NPDAL fields of the NVM Command Set Specific Identify > > > Namespace structure. So use these values to compute discard_granularity. > > > > > > Also fix the use of the OPTPERF field to better comply with version 2.1 > > > of the NVMe spec. > > > > > > Update the target side to report NPDGL and NPDAL as well, in case the > > > discard granularity doesn't fit in the 16-bit NPDG and NPDA fields. > > > > This series looks good to me. I'll queue it up later this week. I just > > want to get a pull request for my currently way-behind 7.0 nvme commits, > > then rebase the tree for new stuff. > > Hi Keith, I see this series in the nvme-7.1 tree, but it looks like > you might have accidentally applied v4 instead of v5? I don't see a > few of the changes I made in response to your comments on the last > revision. Oh, thanks for the notice! I'll take a look and fix it up.