From: Keith Busch <kbusch@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <kbusch@meta.com>, linux-nvme@lists.infradead.org
Subject: Re: [PATCHv2 1/2] nvme-pci: add support for sgl metadata
Date: Wed, 13 Nov 2024 08:48:36 -0700 [thread overview]
Message-ID: <ZzTKVN_1BdNtIuJx@kbusch-mbp> (raw)
In-Reply-To: <20241113045812.GB20379@lst.de>
On Wed, Nov 13, 2024 at 05:58:12AM +0100, Christoph Hellwig wrote:
> 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?
Ack on all suggestions.
next prev parent reply other threads:[~2024-11-13 15:48 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
2024-11-13 15:48 ` Keith Busch [this message]
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=ZzTKVN_1BdNtIuJx@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=hch@lst.de \
--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