From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f97.google.com (mail-dl1-f97.google.com [74.125.82.97]) (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 DE6A73A9D87 for ; Tue, 24 Feb 2026 17:15:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.97 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771953305; cv=none; b=uKEmDIl11aRTpGgJif5zCYmtbd3gg02HCiZfH5E4SAWmsrhotszXFUTxjuNusf7ErM7TBZ/88srmiUAnbkuGX/LiFpK0UPMH6DfVFQqCtE57pIhcQ4XgZ2AyH2U5KWa7b5VF55ljRSqL5a6jEFxVKt7rlnsJCuUmdU9scaPXkqU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771953305; c=relaxed/simple; bh=fps2/8dqqO4k2Lj+C/UvTyp6DIWUCCzBx+IebxpvREo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pJ4XgoaOGFeuxx3no+BI2TY9eDWQWPQqtr06Cg17vgenlP6MvwgajaA0tcf4kb6e3vj7AB1lzFJfyt1qT7fSqdufjixvjaYRlxmA5EV3veiDzqkUUOwT3okMUSwbpn2IvMmZfLf44kFdk0WBKMw81FIuGUGrLYRIl7vFeaC4rQ0= 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=Si7E1EG2; arc=none smtp.client-ip=74.125.82.97 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="Si7E1EG2" Received: by mail-dl1-f97.google.com with SMTP id a92af1059eb24-1273882d901so318980c88.1 for ; Tue, 24 Feb 2026 09:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1771953303; x=1772558103; 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=3NkdLz8yeL0qjqcdMwFc/Rt+8wFzIyO9CzdhRe+Sgx0=; b=Si7E1EG2o/Og9RT/RlI0uedKKN/+FjSUr5Atoju1Fnt2XPIDZ6Pg+TKHKCRTqbE8UK 84bBf15rV24qDR0HF/8dX3HkG7X7ZFUg1I/RT19PaGpObNieazGwRr/bY2r/aTAu9plr JkaNNXvLEQICxE/LOR8ixOqpPqrNQJL9hzba234YvFUwo3Vw3H7bZxyPbmgvi0uf2msd 0jaNL0nzIzOB94kPJJpn1b8zyh8IY8PHJM+AojYPdMHevsVdJLMVy1R/fo7iriHUDivc TsQ0/ooMKL1CTJBcVixIKpRsd2JONCfmLEv4JFBM4VWIryj4WqDO2JYsZ06gWUzY1IvR nT4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771953303; x=1772558103; 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=3NkdLz8yeL0qjqcdMwFc/Rt+8wFzIyO9CzdhRe+Sgx0=; b=gpWCXQHLSCNZWBxVsvmJZLWtUZmu3F1TmQsxOuX6NbCORroxbPkylYO3325E6a36mi 8VcUDPggqbjQTx9AWo5T4ecCXNJg+OJMquHsq+rMPIIlb8O4Nob0BoIRdJdQ+goA8Grm ae5JAKLCUJg81PquojruzVPC24EKMvrsNZ5h03VBa2SZK2AXwe9su2D845qopSCwmhDI VlLi+R8l181gl8/6dWjbQUQPiFJEgpBe0kB04bjhYHvFpV9/kFgEiGlt61DVGmBOMCX8 tS+2bKStCk55eVYQAsYyHIc9uEB04X0897Ftu3TgPs2BgX5F9dx1rmztnn67/9Mq9jkI 1kqw== X-Forwarded-Encrypted: i=1; AJvYcCUkU9BXsTCuewPTO2AurODsj+86i6kIXFcqj4e8ZXeZdGToXbRoSzKjoA+oF3dgbwEQNH0k9fGaKZOWuv0=@vger.kernel.org X-Gm-Message-State: AOJu0Yx0OicmmCH+14/34FOe/LVvkjgk4MvDiu87eaS3ySlOG+Nbjkvy fCFm2m6PJYbtZdlolSIaoPepfLG/ntkz8UysdPTCOFtlqIU+grQdu3D4IyYbKxHBiGS9/uXYMdl GjlDIpqMGMDxP9eSIFf7i9GVY4Hrh25AcWCdB X-Gm-Gg: AZuq6aKdeNfW/Aer2qSViA1x9l1e9byKQq8MzkokX3ihwNWixZYp8uK6d8VtySOCEwO SMKSoF63pAUQp6p7uDZO3h/AKECpdFJ5X5DM0eD37d42M593IzLTaWeiabOjc1oKdGYOck9i+8s 1SkZjqRyiZuwGW3azlNb712cup7a9ddm3s2Nx8ZWgaez6Q9wUoSRB6fILM73GpIli2BEQe40abi ZUCiepcuD6m/BaG7kMaUBup+Uzc6S2ELK+bVT1j87yHpZ5iCnnaffzjT6kdcjb/Lr0TH2qVBK9S t1Y19oQg8bkMUhczOTonWXD4ogyK6mUjPODahNJfvrMtHWVHXrP9N10X9G/XUuP/7Ktl94eI6zj YSbsIa0hdYiebFWbqnZdkQ6DdPau6EnyuyOBbEMn/3LEJ4GeB4x9gSQ== X-Received: by 2002:a05:7022:2589:b0:11e:332:1e01 with SMTP id a92af1059eb24-1276ad03aa3mr2503487c88.3.1771953302910; Tue, 24 Feb 2026 09:15:02 -0800 (PST) Received: from c7-smtp-2023.dev.purestorage.com ([208.88.159.128]) by smtp-relay.gmail.com with ESMTPS id a92af1059eb24-1276af6346fsm1377580c88.5.2026.02.24.09.15.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Feb 2026 09:15:02 -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 D4E3B340705; Tue, 24 Feb 2026 10:15:01 -0700 (MST) Received: by dev-csander.dev.purestorage.com (Postfix, from userid 1557716354) id CFEBAE41254; Tue, 24 Feb 2026 10:15:01 -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 v3 6/8] nvme: set discard_granularity from NPDG/NPDA Date: Tue, 24 Feb 2026 10:14:35 -0700 Message-ID: <20260224171437.3175993-7-csander@purestorage.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20260224171437.3175993-1-csander@purestorage.com> References: <20260224171437.3175993-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: 8bit 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 2b433478f328..a9e8936b480d 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 = UINT_MAX; lim->dma_alignment = 3; } static bool nvme_update_disk_info(struct nvme_ns *ns, struct nvme_id_ns *id, - struct queue_limits *lim) + struct nvme_id_ns_nvm *nvm, struct queue_limits *lim) { struct nvme_ns_head *head = ns->head; struct nvme_ctrl *ctrl = ns->ctrl; u32 bs = 1U << head->lba_shift; u32 atomic_bs, phys_bs, io_opt = 0; + u32 npdg = 1, npda = 1; bool valid = true; u8 optperf; /* * 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 *ns, struct nvme_id_ns *id, else if (ctrl->oncs & NVME_CTRL_ONCS_DSM) lim->max_hw_discard_sectors = UINT_MAX; else lim->max_hw_discard_sectors = 0; - lim->discard_granularity = 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 = le32_to_cpu(nvm->npdgl); + else if (optperf & 0x1) + npdg = from0based(id->npdg); + if (optperf & 0x2 && nvm && nvm->npdal) + npda = le32_to_cpu(nvm->npdal); + else if (optperf) + npda = from0based(id->npda); + lim->discard_granularity = max(npdg, npda) * lim->logical_block_size; if (ctrl->dmrl) lim->max_discard_segments = ctrl->dmrl; else lim->max_discard_segments = NVME_DSM_MAX_RANGES; @@ -2380,11 +2407,11 @@ static int nvme_update_ns_info_block(struct nvme_ns *ns, ns->head->nuse = le64_to_cpu(id->nuse); capacity = 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 = 0; if (IS_ENABLED(CONFIG_BLK_DEV_ZONED) && ns->head->ids.csi == NVME_CSI_ZNS) nvme_update_zone_info(ns, &lim, &zi); -- 2.45.2