From nobody Tue Apr 7 18:45:32 2026 Received: from mail-pl1-f226.google.com (mail-pl1-f226.google.com [209.85.214.226]) (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 ACB6444CAEF for ; Thu, 26 Feb 2026 19:04:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.226 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772132670; cv=none; b=IDot4Cr5Peyaesm2BOhb7AUqRYDNj5O19aCqqPQxjSq3ZTNVAnZrdZttFUDCuz6WUovqlGSrcbqRYpjhcNReWnYTSOjrMusveGI+lfKmNyZjknv+Tlz7bl8DzCgKycNhJv0DsDIkptrHcIwH46rVHIwuLDbMKU3yS6MZi4+Xqts= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772132670; c=relaxed/simple; bh=EZCW6O28GdqODIWRdUFqKXljk8iskdLu5cK2y6OJe5o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jgYeXyds0MipsYlM9QxJYLmcX3MFoDSvW15pPuqqFQdL5Q0OBgNtRCX97bnRVfsRnR/+iaMElLPgRLnwedQEROFm9xL53a3x76SwEeKAViKuLaKO+UUdILAg+/VP43jvl/a922yLSFJSUfkaFnYjE8S/wYpiRY4CUGguh0OHp1M= 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=RMYH9Kcp; arc=none smtp.client-ip=209.85.214.226 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="RMYH9Kcp" Received: by mail-pl1-f226.google.com with SMTP id d9443c01a7336-2a8fba89cb5so957435ad.2 for ; Thu, 26 Feb 2026 11:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1772132662; x=1772737462; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=MCbjgYzJFkz4xvVSToR+yG/8UzWEaIR4Ya96q2o9rOo=; b=RMYH9KcpT5WLw9FvgiIj43pc4CeWCfu7fbEnvaUX6Xnd6bno1Pp+wNSFtWrIOdWe9/ QG4R9jyYgadTLctEYRecH7WRfvPkvY5aZkgNH+UAfUQgWgxmhhNhS44j9vldACVunKrk dvHJ6gy6qHqgrQC211bO9BE5nI+XxIikjsDLeioW7zhBhrppoq/RBNL4i5gNiw8bGMZq G3Xv/Hht5HaSGnhRoppiTJ2hIiXleDYGzD68eBg/HexzF9KKAwkEoDkQgguxj9TO6ueK 9gVeNlIpjhFPMFotBZa35oryAsvuhVVjSHgKcLZjemN7vVwLS2XvlLAMN8Vya9q9a7HM 7KsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772132662; x=1772737462; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=MCbjgYzJFkz4xvVSToR+yG/8UzWEaIR4Ya96q2o9rOo=; b=liCWoahQPt2nILsGMc2UYdANycWKwR2eGEQfedJd+d1AAQF3Fkh0l+KT8Uj2k1l8EW p2NCv1VAIw8/fzpQqV+IKr28XHHCTLXunZOA/A9Uxm9kwfNRtNVQjm9czb1b2/DPPdbS Gj3UDQt4g3V21VcgJfIZ2aCvpXrmhjfJuDBzmUNlHx2idv0U87K4X82jC9g/UoOVA4hB HliF7mgBS3Ql3QbbQhfuGUUrLZUXkyxO2AyVZjqm/29yWRmzeNFQg7cRs+vu0+aYn/Rc fwJ1ttsS7ahRakhQWo9shbmYlldpbeoQFiQgDkreOcnmysVIHJPIFlbNTSYjZKZEbdbZ FkBQ== X-Forwarded-Encrypted: i=1; AJvYcCUkjyV4vV3Nic5tQeUDIdM1idHeLLr3A4VCC/lEcVeMWKzHnVulBydqisD9cmYnNTDATOPhAVNaPNKoZ/Y=@vger.kernel.org X-Gm-Message-State: AOJu0Yz4hEkUyIsfZ/Ed51jMioIrPy6lqCq9QfeTyHiZDdI3nS3rmZ0z rrjBzjglKdAOM7Tc2yXaHYmKU04JdTtNK50TL/9YR/67gWivy+Sa1OZ2EVFuQkRQgqzVt/NrFEk obrch/I4107gVWgLNqxyCfViYDkmSDD1w+jvcfN3VCI1fywmr+b0o X-Gm-Gg: ATEYQzxEIsucX4UCmqBehzM8vtLysDj5gaySf57H0+JK/7qE+yt3cSCpjAW4d5aRnfq JMHMY52WDOzJQ7mTdWe6l0RoO2klAemgRkDwBzPFx8yFNnBkkT9kiQ1D+DqrGvMr+zSLYeKJlsZ G2YYB6TXyPyUGx2kkQQyQ4L4Wb8jfHlTwnF/SUX2O6KjCZhl5k9QxB7RZ5oC737VTh2XQCs1bzI BGUdF8ne9gIMn1V8vmcqusRXvDjal72L6TKgutJMkDvEBM0dG+zIQFUtmtmkteKrrN8ykAKecdG 2pUpQ6eE8jPhzKm8AFfQxfgyA5SZ7YR42DNiW1wM8HjNQqN7lR7UG2IGUnVzjkxJsNeOWRoTeCU 5/OKEz3bIao4EBa+qZAJSG3XyDViL8y0A/MzsU8s= X-Received: by 2002:a17:90b:2d84:b0:358:f02c:b94e with SMTP id 98e67ed59e1d1-35965ce4b48mr126053a91.6.1772132661836; Thu, 26 Feb 2026 11:04:21 -0800 (PST) Received: from c7-smtp-2023.dev.purestorage.com ([2620:125:9017:12:36:3:5:0]) by smtp-relay.gmail.com with ESMTPS id d9443c01a7336-2adfb16ae40sm3247365ad.13.2026.02.26.11.04.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Feb 2026 11:04:21 -0800 (PST) X-Relaying-Domain: purestorage.com Received: from dev-csander.dev.purestorage.com (dev-csander.dev.purestorage.com [10.112.29.101]) by c7-smtp-2023.dev.purestorage.com (Postfix) with ESMTP id AD6D8342161; Thu, 26 Feb 2026 12:04:20 -0700 (MST) Received: by dev-csander.dev.purestorage.com (Postfix, from userid 1557716354) id A8554E41254; Thu, 26 Feb 2026 12:04:20 -0700 (MST) From: Caleb Sander Mateos To: Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , Chaitanya Kulkarni Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Caleb Sander Mateos Subject: [PATCH v4 6/8] nvme: set discard_granularity from NPDG/NPDA Date: Thu, 26 Feb 2026 12:04:13 -0700 Message-ID: <20260226190416.297725-7-csander@purestorage.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20260226190416.297725-1-csander@purestorage.com> References: <20260226190416.297725-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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Currently, nvme_config_discard() always sets the discard_granularity queue limit to the logical block size. However, NVMe namespaces can advertise a larger preferred discard granularity in the NPDG or NPDA field of the Identify Namespace structure or the NPDGL or NPDAL fields of the I/O Command Set Specific Identify Namespace structure. Use these fields to compute the discard_granularity limit. The logic is somewhat involved. First, the fields are optional. NPDG is only reported if the low bit of OPTPERF is set in NSFEAT. NPDA is reported if any bit of OPTPERF is set. And NPDGL and NPDAL are reported if the high bit of OPTPERF is set. NPDGL and NPDAL can also each be set to 0 to opt out of reporting a limit. I/O Command Set Specific Identify Namespace may also not be supported by older NVMe controllers. Another complication is that multiple values may be reported among NPDG, NPDGL, NPDA, and NPDAL. The spec says to prefer the values reported in the L variants. The spec says NPDG should be a multiple of NPDA and NPDGL should be a multiple of NPDAL, but it doesn't specify a relationship between NPDG and NPDAL or NPDGL and NPDA. So use the maximum of the reported NPDG(L) and NPDA(L) values as the discard_granularity. Signed-off-by: Caleb Sander Mateos --- drivers/nvme/host/core.c | 33 ++++++++++++++++++++++++++++++--- 1 file changed, 30 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 14e52b260f5d..20441985cad1 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -2055,16 +2055,17 @@ static void nvme_set_ctrl_limits(struct nvme_ctrl *= ctrl, lim->max_segment_size =3D UINT_MAX; lim->dma_alignment =3D 3; } =20 static bool nvme_update_disk_info(struct nvme_ns *ns, struct nvme_id_ns *i= d, - struct queue_limits *lim) + struct nvme_id_ns_nvm *nvm, struct queue_limits *lim) { struct nvme_ns_head *head =3D ns->head; struct nvme_ctrl *ctrl =3D ns->ctrl; u32 bs =3D 1U << head->lba_shift; u32 atomic_bs, phys_bs, io_opt =3D 0; + u32 npdg =3D 1, npda =3D 1; bool valid =3D true; u8 optperf; =20 /* * The block layer can't support LBA sizes larger than the page size @@ -2113,11 +2114,37 @@ static bool nvme_update_disk_info(struct nvme_ns *n= s, struct nvme_id_ns *id, else if (ctrl->oncs & NVME_CTRL_ONCS_DSM) lim->max_hw_discard_sectors =3D UINT_MAX; else lim->max_hw_discard_sectors =3D 0; =20 - lim->discard_granularity =3D lim->logical_block_size; + /* + * NVMe namespaces advertise both a preferred deallocate granularity + * (for a discard length) and alignment (for a discard starting offset). + * However, Linux block devices advertise a single discard_granularity. + * From NVM Command Set specification 1.1 section 5.2.2, the NPDGL/NPDAL + * fields in the NVM Command Set Specific Identify Namespace structure + * are preferred to NPDG/NPDA in the Identify Namespace structure since + * they can represent larger values. However, NPDGL or NPDAL may be 0 if + * unsupported. NPDG and NPDA are 0's based. + * From Figure 115 of NVM Command Set specification 1.1, NPDGL and NPDAL + * are supported if the high bit of OPTPERF is set. NPDG is supported if + * the low bit of OPTPERF is set. NPDA is supported if either is set. + * NPDG should be a multiple of NPDA, and likewise NPDGL should be a + * multiple of NPDAL, but the spec doesn't say anything about NPDG vs. + * NPDAL or NPDGL vs. NPDA. So compute the maximum instead of assuming + * NPDG(L) is the larger. If neither NPDG, NPDGL, NPDA, nor NPDAL are + * supported, default the discard_granularity to the logical block size. + */ + if (optperf & 0x2 && nvm && nvm->npdgl) + npdg =3D le32_to_cpu(nvm->npdgl); + else if (optperf & 0x1) + npdg =3D from0based(id->npdg); + if (optperf & 0x2 && nvm && nvm->npdal) + npda =3D le32_to_cpu(nvm->npdal); + else if (optperf) + npda =3D from0based(id->npda); + lim->discard_granularity =3D max(npdg, npda) * lim->logical_block_size; =20 if (ctrl->dmrl) lim->max_discard_segments =3D ctrl->dmrl; else lim->max_discard_segments =3D NVME_DSM_MAX_RANGES; @@ -2378,11 +2405,11 @@ static int nvme_update_ns_info_block(struct nvme_ns= *ns, ns->head->nuse =3D le64_to_cpu(id->nuse); capacity =3D nvme_lba_to_sect(ns->head, le64_to_cpu(id->nsze)); nvme_set_ctrl_limits(ns->ctrl, &lim, false); nvme_configure_metadata(ns->ctrl, ns->head, id, nvm, info); nvme_set_chunk_sectors(ns, id, &lim); - if (!nvme_update_disk_info(ns, id, &lim)) + if (!nvme_update_disk_info(ns, id, nvm, &lim)) capacity =3D 0; =20 if (IS_ENABLED(CONFIG_BLK_DEV_ZONED) && ns->head->ids.csi =3D=3D NVME_CSI_ZNS) nvme_update_zone_info(ns, &lim, &zi); --=20 2.45.2