From: Leon Romanovsky <leon@kernel.org>
To: Christoph Hellwig <hch@lst.de>, Chuck Lever <cel@kernel.org>
Cc: Jason Gunthorpe <jgg@nvidia.com>, NeilBrown <neilb@ownmail.net>,
Jeff Layton <jlayton@kernel.org>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
linux-rdma@vger.kernel.org, linux-nfs@vger.kernel.org,
Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [PATCH v2 1/4] RDMA/core: add bio_vec based RDMA read/write API
Date: Wed, 21 Jan 2026 10:48:40 +0200 [thread overview]
Message-ID: <20260121084840.GX13201@unreal> (raw)
In-Reply-To: <20260121084217.GA16458@lst.de>
On Wed, Jan 21, 2026 at 09:42:17AM +0100, Christoph Hellwig wrote:
> On Tue, Jan 20, 2026 at 09:31:21AM -0500, Chuck Lever wrote:
> > From: Chuck Lever <chuck.lever@oracle.com>
> >
> > The existing rdma_rw_ctx_init() API requires callers to construct a
> > scatterlist, which is then DMA-mapped page by page. Callers that
> > already have data in bio_vec form (such as the NVMe-oF target) must
> > first convert to scatterlist, adding overhead and complexity.
> >
> > Introduce rdma_rw_ctx_init_bvec() and rdma_rw_ctx_destroy_bvec() to
> > accept bio_vec arrays directly. The new helpers use dma_map_phys()
> > for hardware RDMA devices and virtual addressing for software RDMA
> > devices (rxe, siw), avoiding intermediate scatterlist construction.
> >
> > Memory registration (MR) path support is deferred to a follow-up
> > series; callers requiring MR-based transfers (iWARP devices or
> > force_mr=1) receive -EOPNOTSUPP and should use the scatterlist API.
> >
> > Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> > ---
> > drivers/infiniband/core/rw.c | 210 +++++++++++++++++++++++++++++++++++
> > include/rdma/ib_verbs.h | 42 +++++++
> > include/rdma/rw.h | 10 ++
> > 3 files changed, 262 insertions(+)
> >
> > diff --git a/drivers/infiniband/core/rw.c b/drivers/infiniband/core/rw.c
> > index 6354ddf2a274..59f32fecf3df 100644
> > --- a/drivers/infiniband/core/rw.c
> > +++ b/drivers/infiniband/core/rw.c
> > @@ -4,6 +4,7 @@
> > */
> > #include <linux/memremap.h>
> > #include <linux/moduleparam.h>
> > +#include <linux/overflow.h>
> > #include <linux/slab.h>
> > #include <linux/pci-p2pdma.h>
> > #include <rdma/mr_pool.h>
> > @@ -274,6 +275,111 @@ static int rdma_rw_init_single_wr(struct rdma_rw_ctx *ctx, struct ib_qp *qp,
> > return 1;
> > }
> >
> > +static int rdma_rw_init_single_wr_bvec(struct rdma_rw_ctx *ctx,
> > + struct ib_qp *qp, const struct bio_vec *bvec,
>
> Nit: maybe rename bvec to bvecs or bvec_table to make it clear this
> is the base array that the iter operates on?
>
> > + struct bvec_iter *iter,
> > + u64 remote_addr, u32 rkey, enum dma_data_direction dir)
>
> Nit 2: this can be condensed a little:
>
> > + struct bvec_iter *iter, u64 remote_addr, u32 rkey,
> > + enum dma_data_direction dir)
>
> > +static int rdma_rw_init_map_wrs_bvec(struct rdma_rw_ctx *ctx, struct ib_qp *qp,
> > + const struct bio_vec *bvec, u32 nr_bvec,
> > + struct bvec_iter *iter,
> > + u64 remote_addr, u32 rkey, enum dma_data_direction dir)
Don't you both think these functions take too many arguments? It might be
worth introducing something like "struct rdma_rw_init_attrs" and passing
that instead.
At the end, these functions are for you to use.
Thanks
>
> Same here.
>
> Otherwise looks good:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
next prev parent reply other threads:[~2026-01-21 8:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 14:31 [PATCH v2 0/4] Add a bio_vec based API to core/rw.c Chuck Lever
2026-01-20 14:31 ` [PATCH v2 1/4] RDMA/core: add bio_vec based RDMA read/write API Chuck Lever
2026-01-21 8:42 ` Christoph Hellwig
2026-01-21 8:48 ` Leon Romanovsky [this message]
2026-01-21 8:57 ` Christoph Hellwig
2026-01-21 10:16 ` Leon Romanovsky
2026-01-21 8:56 ` Christoph Hellwig
2026-01-21 14:14 ` Chuck Lever
2026-01-21 14:57 ` Christoph Hellwig
2026-01-21 15:10 ` Chuck Lever
2026-01-20 14:31 ` [PATCH v2 2/4] RDMA/core: use IOVA-based DMA mapping for bvec RDMA operations Chuck Lever
2026-01-21 8:51 ` Christoph Hellwig
2026-01-20 14:31 ` [PATCH v2 3/4] RDMA/core: add MR support for bvec-based " Chuck Lever
2026-01-21 9:05 ` Christoph Hellwig
2026-01-20 14:31 ` [PATCH v2 4/4] svcrdma: use bvec-based RDMA read/write API Chuck Lever
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=20260121084840.GX13201@unreal \
--to=leon@kernel.org \
--cc=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=hch@lst.de \
--cc=jgg@nvidia.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=neilb@ownmail.net \
--cc=okorniev@redhat.com \
--cc=tom@talpey.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.