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.

v5:
- Only issue NVM Command Set Specific Identify Namespace if controller
  version supports CNS value (Keith)
- Check for multiplication overflow (Keith)

v4:
- Issue NVM Command Set Specific Identify Namespace regardless of
  controller version (Keith)

v3:
- Introduce from0based() (Christoph)
- Fix merge conflict resolution (Keith)
- Add more comments (Christoph)
- Add Reviewed-by tags (Christoph)

v2:
- Only use low bit of OPTPERF on pre-2.1 controllers (Christoph)
- Add Reviewed-by tags (Christoph)

Caleb Sander Mateos (8):
  nvme: add preferred I/O size fields to struct nvme_id_ns_nvm
  nvme: fold nvme_config_discard() into nvme_update_disk_info()
  nvme: update nvme_id_ns OPTPERF constants
  nvme: always issue I/O Command Set specific Identify Namespace
  nvme: add from0based() helper
  nvme: set discard_granularity from NPDG/NPDA
  nvmet: use NVME_NS_FEAT_OPTPERF_SHIFT
  nvmet: report NPDGL and NPDAL

 drivers/nvme/host/core.c          | 86 +++++++++++++++++++++----------
 drivers/nvme/host/nvme.h          |  6 +++
 drivers/nvme/target/admin-cmd.c   |  2 +
 drivers/nvme/target/io-cmd-bdev.c | 19 +++++--
 drivers/nvme/target/nvmet.h       |  2 +
 include/linux/nvme.h              | 15 +++++-
 6 files changed, 96 insertions(+), 34 deletions(-)

-- 
2.45.2

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.

On Mon, Mar 2, 2026 at 10:54 AM Keith Busch <kbusch@kernel.org> 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.

Thanks,
Caleb

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 <kbusch@kernel.org> 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.

On Mon, Mar 2, 2026 at 10:54 AM Keith Busch <kbusch@kernel.org> 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.

Sounds good, no rush

Thanks,
Caleb