Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@meta.com>
Cc: linux-nvme@lists.infradead.org, hch@lst.de,
	Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCHv2 1/2] nvme-pci: add support for sgl metadata
Date: Wed, 13 Nov 2024 05:58:12 +0100	[thread overview]
Message-ID: <20241113045812.GB20379@lst.de> (raw)
In-Reply-To: <20241112210620.2650523-2-kbusch@meta.com>

On Tue, Nov 12, 2024 at 01:06:19PM -0800, Keith Busch wrote:
> Supporting this mode allows merging requests with metadata that wouldn't
> be possible otherwise, and creating user space requests that straddle
> physically discontiguous pages.

Not just merging, but also creating :)  I.e. it allows to transfer
multiple non-contiguous metadata segements.

> 
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index e119ba0f8ab8b..12e5064b9cba0 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -1985,6 +1985,9 @@ static void nvme_set_ctrl_limits(struct nvme_ctrl *ctrl,
>  	lim->max_segments = min_t(u32, USHRT_MAX,
>  		min_not_zero(nvme_max_drv_segments(ctrl), ctrl->max_segments));
>  	lim->max_integrity_segments = ctrl->max_integrity_segments;
> +	if (lim->max_integrity_segments > 1 &&
> +	    !nvme_ctrl_meta_sgl_supported(ctrl))
> +		lim->max_integrity_segments = 1;

Despite the general mess about the SGLS field in the nvme spec, the meta
sgls bit really is a PCIe-only feasture, and this will break metadata
support on RDMA.  The nvme_ctrl_meta_sgl_supported needs to be in pci.c
to set ctrl->max_integrity_segments based on it.

> +static inline bool nvme_ctrl_meta_sgl_supported(struct nvme_ctrl *ctrl)
> +{
> +	return ctrl->sgls & NVME_CTRL_SGLS_MPTR;
> +}

.. and thus I'd move this to pci.c (or just drop the helper).

> +	NVME_CTRL_SGLS_MPTR                     = 1 << 19,

Maybe give the other fields in SGLS a name as well?



  reply	other threads:[~2024-11-13  4:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-12 21:06 [PATCHv2 0/2] Using SGLs for userspace commands Keith Busch
2024-11-12 21:06 ` [PATCHv2 1/2] nvme-pci: add support for sgl metadata Keith Busch
2024-11-13  4:58   ` Christoph Hellwig [this message]
2024-11-13 15:48     ` Keith Busch
2024-11-12 21:06 ` [PATCHv2 2/2] nvme-pci: use sgls for all user requests if possible Keith Busch
2024-11-13  4:58   ` Christoph Hellwig
2024-11-13 15:48     ` Keith Busch
2024-11-14  5:56       ` Christoph Hellwig
2024-11-14 15:53         ` Keith Busch
2024-11-14 16:42           ` Christoph Hellwig
2024-11-14 17:29             ` Keith Busch
2024-11-13  4:50 ` [PATCHv2 0/2] Using SGLs for userspace commands Christoph Hellwig
2024-11-13 15:50   ` Keith Busch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241113045812.GB20379@lst.de \
    --to=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=kbusch@meta.com \
    --cc=linux-nvme@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox