From: Christoph Hellwig <hch@lst.de>
To: Pavel Begunkov <asml.silence@gmail.com>
Cc: "Jens Axboe" <axboe@kernel.dk>, "Keith Busch" <kbusch@kernel.org>,
"Christoph Hellwig" <hch@lst.de>,
"Sagi Grimberg" <sagi@grimberg.me>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org,
io-uring@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Christian Brauner" <brauner@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
"Nitesh Shetty" <nj.shetty@samsung.com>,
"Kanchan Joshi" <joshi.k@samsung.com>,
"Anuj Gupta" <anuj20.g@samsung.com>,
"Tushar Gohad" <tushar.gohad@intel.com>,
"William Power" <william.power@intel.com>,
"Phil Cayton" <phil.cayton@intel.com>,
"Jason Gunthorpe" <jgg@nvidia.com>,
"Damien Le Moal" <dlemoal@kernel.org>,
"Alasdair Kergon" <agk@redhat.com>,
"Mike Snitzer" <snitzer@kernel.org>,
"Mikulas Patocka" <mpatocka@redhat.com>,
"Benjamin Marzinski" <bmarzins@redhat.com>,
"Vishal Verma" <vishal.l.verma@intel.com>,
"David Sterba" <dsterba@suse.com>,
"Ilya Dryomov" <idryomov@gmail.com>,
dm-devel@lists.linux.dev, nvdimm@lists.linux.dev,
linux-btrfs@vger.kernel.org, ceph-devel@vger.kernel.org
Subject: Re: [PATCH v4 09/14] nvme-pci: add SGL support for the dmabuf path
Date: Wed, 29 Jul 2026 09:21:17 +0200 [thread overview]
Message-ID: <20260729072117.GI9534@lst.de> (raw)
In-Reply-To: <5c2e9c3bdd3e87c0c9a6e4395ea199002b83fd36.1785274111.git.asml.silence@gmail.com>
On Tue, Jul 28, 2026 at 10:29:21PM +0100, Pavel Begunkov wrote:
> From: Anuj Gupta <anuj20.g@samsung.com>
>
> Add SGL support in addition to PRP for dmabuf-backed requests,
> coalescing the mapping's sg_table into NVMe SGL data descriptors.
>
> Signed-off-by: Anuj Gupta <anuj20.g@samsung.com>
> [pavel: rebased]
> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
> ---
> drivers/nvme/host/pci.c | 191 +++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 187 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index f1b67c191892..cbb321fb7c50 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -1287,12 +1287,18 @@ static blk_status_t nvme_pci_setup_data_prp(struct request *req,
> return BLK_STS_IOERR;
> }
>
> +static void nvme_pci_sgl_set_data_addr(struct nvme_sgl_desc *sge,
> + dma_addr_t addr, u32 len)
> +{
> + sge->addr = cpu_to_le64(addr);
> + sge->length = cpu_to_le32(len);
> + sge->type = NVME_SGL_FMT_DATA_DESC << 4;
> +}
> +
> static void nvme_pci_sgl_set_data(struct nvme_sgl_desc *sge,
> struct blk_dma_iter *iter)
> {
> - sge->addr = cpu_to_le64(iter->addr);
> - sge->length = cpu_to_le32(iter->len);
> - sge->type = NVME_SGL_FMT_DATA_DESC << 4;
> + nvme_pci_sgl_set_data_addr(sge, iter->addr, iter->len);
> }
The naming is a bit confusing (and me passing the iter to
nvme_pci_sgl_set_data is probably at faul for that). So maybe
spin out a prep patch to rename the old nvme_pci_sgl_set_data
to nvme_pci_dma_iter_set_sgl or so, and then add the new one
as nvme_pci_sgl_set_data (as before the dma_iter conversion).
>
> +static unsigned int nvme_pci_dmabuf_sgl_nents(struct request *req,
> + dma_addr_t *first_dma,
> + u32 *first_len)
This is a really good example why the aligning to the opening braces
produces totally unreadble code..
But I also don't understand what the use case for this function
is to start with. struct sg_table tells us how many segments
exist on the DMA side in the nents member, which should be just
fine for the SGL threshold calculation.
> +{
> + struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
> + struct bio *bio = req->bio;
> + struct nvme_dmabuf_map *map = to_nvme_dmabuf_map(bio->bi_dmabuf_map);
> + size_t length = blk_rq_payload_bytes(req);
> + struct nvme_sgl_desc *sg_list = NULL;
> + dma_addr_t sgl_dma = 0, last_end = 0;
> + unsigned int mapped = 0;
> + unsigned long tmp;
> + struct scatterlist *sg;
> + size_t offset, remaining;
> + bool have = false;
> +
> + if (!entries)
> + return BLK_STS_IOERR;
> + if (entries > NVME_MAX_SEGS)
> + return BLK_STS_AGAIN;
Given that the block layer enforced data in rw/command and the
max_segments limit, why do we need the extra check here?
> + continue;
> + }
> +
> + addr += offset;
> + sg_len -= offset;
> + offset = 0;
> +
> + while (sg_len && remaining) {
These can't be false on the first iteration, so maybe turn this into
a do {} while loop?
> + u32 chunk = min_t(size_t, remaining, sg_len);
> +
> + if (have && last_end == addr) {
> + u32 old = le32_to_cpu(sg_list[mapped - 1].length);
> +
> + sg_list[mapped - 1].length = cpu_to_le32(old + chunk);
Overly long line.
> + } else {
> + if (WARN_ON_ONCE(mapped == entries))
> + goto err_free;
> + nvme_pci_sgl_set_data_addr(&sg_list[mapped++],
> + addr, chunk);
> + }
Why do we need this merging? dma_map_sg should have already done
any interesting merging, or am I missing something?
> + if (use_sgl != SGL_UNSUPPORTED) {
> + dma_addr_t first_dma;
> + u32 first_len;
> + unsigned int entries;
> +
> + entries = nvme_pci_dmabuf_sgl_nents(req, &first_dma,
> + &first_len);
> +
> + if (use_sgl == SGL_FORCED) {
> + ret = nvme_rq_setup_dmabuf_sgl(req, nvmeq,
> + entries, first_dma, first_len);
> + return ret == BLK_STS_AGAIN ? BLK_STS_IOERR : ret;
> + }
> +
> + if (sgl_threshold && entries &&
> + DIV_ROUND_UP(blk_rq_payload_bytes(req), entries) >=
> + sgl_threshold) {
> + ret = nvme_rq_setup_dmabuf_sgl(req, nvmeq,
> + entries, first_dma, first_len);
> + if (ret != BLK_STS_AGAIN)
> + return ret;
> + }
> + }
Various overly long lines. Please factor out a helper for the
decisions to use sgl vs not instead of open coding it here.
next prev parent reply other threads:[~2026-07-29 7:21 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 21:29 [PATCH v4 00/14] Add dmabuf read/write via io_uring Pavel Begunkov
2026-07-28 21:29 ` [PATCH v4 01/14] dma-buf: introduce initial file I/O infrastructure Pavel Begunkov
2026-07-29 6:59 ` Christoph Hellwig
2026-07-29 10:37 ` Pavel Begunkov
2026-07-29 11:28 ` Christoph Hellwig
2026-07-29 13:11 ` Pavel Begunkov
2026-07-28 21:29 ` [PATCH v4 02/14] iov_iter: add iterator type for dmabuf maps Pavel Begunkov
2026-07-29 6:59 ` Christoph Hellwig
2026-07-29 10:40 ` Pavel Begunkov
2026-07-28 21:29 ` [PATCH v4 03/14] block: rename bi_bvec_done Pavel Begunkov
2026-07-29 7:00 ` Christoph Hellwig
2026-07-28 21:29 ` [PATCH v4 04/14] block: always adjust bi_offset on bio_advance_iter Pavel Begunkov
2026-07-29 7:00 ` Christoph Hellwig
2026-07-28 21:29 ` [PATCH v4 05/14] block: move bvec init into __bio_clone Pavel Begunkov
2026-07-29 7:00 ` Christoph Hellwig
2026-07-28 21:29 ` [PATCH v4 06/14] block: introduce dma map backed bio type Pavel Begunkov
2026-07-29 7:07 ` Christoph Hellwig
2026-07-29 11:03 ` Pavel Begunkov
2026-07-28 21:29 ` [PATCH v4 07/14] block: forward init_dma_buf_io_ctx to drivers Pavel Begunkov
2026-07-29 7:07 ` Christoph Hellwig
2026-07-28 21:29 ` [PATCH v4 08/14] nvme-pci: implement dma_token backed requests Pavel Begunkov
2026-07-29 7:10 ` Christoph Hellwig
2026-07-29 10:49 ` Pavel Begunkov
2026-07-28 21:29 ` [PATCH v4 09/14] nvme-pci: add SGL support for the dmabuf path Pavel Begunkov
2026-07-29 7:21 ` Christoph Hellwig [this message]
2026-07-29 10:17 ` Anuj Gupta/Anuj Gupta
2026-07-29 11:31 ` Christoph Hellwig
2026-07-29 11:45 ` Pavel Begunkov
2026-07-29 11:55 ` Christoph Hellwig
2026-07-29 13:08 ` Pavel Begunkov
2026-07-28 21:29 ` [PATCH v4 10/14] io_uring/rsrc: introduce buf registration structure Pavel Begunkov
2026-07-28 21:29 ` [PATCH v4 11/14] io_uring/rsrc: extend buffer update Pavel Begunkov
2026-07-29 13:31 ` Anuj Gupta/Anuj Gupta
2026-07-29 13:39 ` Pavel Begunkov
2026-07-28 21:29 ` [PATCH v4 12/14] io_uring/rsrc: add uncloneable regbuf flag Pavel Begunkov
2026-07-28 21:29 ` [PATCH v4 13/14] io_uring/rsrc: add regbuf import flags Pavel Begunkov
2026-07-28 21:29 ` [PATCH v4 14/14] io_uring/rsrc: add dmabuf backed registered buffers Pavel Begunkov
2026-07-29 13:30 ` Anuj Gupta/Anuj Gupta
2026-07-29 13:43 ` Pavel Begunkov
2026-07-29 6:54 ` [PATCH v4 00/14] Add dmabuf read/write via io_uring Christoph Hellwig
2026-07-29 11:28 ` Pavel Begunkov
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=20260729072117.GI9534@lst.de \
--to=hch@lst.de \
--cc=agk@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=anuj20.g@samsung.com \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=bmarzins@redhat.com \
--cc=brauner@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=christian.koenig@amd.com \
--cc=dlemoal@kernel.org \
--cc=dm-devel@lists.linux.dev \
--cc=dri-devel@lists.freedesktop.org \
--cc=dsterba@suse.com \
--cc=idryomov@gmail.com \
--cc=io-uring@vger.kernel.org \
--cc=jgg@nvidia.com \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mpatocka@redhat.com \
--cc=nj.shetty@samsung.com \
--cc=nvdimm@lists.linux.dev \
--cc=phil.cayton@intel.com \
--cc=sagi@grimberg.me \
--cc=snitzer@kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=tushar.gohad@intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=vishal.l.verma@intel.com \
--cc=william.power@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.