From: Leon Romanovsky <leon@kernel.org>
To: Yishai Hadas <yishaih@nvidia.com>
Cc: jgg@ziepe.ca, linux-rdma@vger.kernel.org,
selvin.xavier@broadcom.com, kalesh-anakkur.purayil@broadcom.com,
chengyou@linux.alibaba.com, kaishen@linux.alibaba.com,
tangchengchang@huawei.com, huangjunxian6@hisilicon.com,
abhijit.gangurde@amd.com, allen.hubbe@amd.com,
longli@microsoft.com, kotaranov@microsoft.com,
mkalderon@marvell.com, bryan-bt.tan@broadcom.com,
vishnu.dasa@broadcom.com, maorg@nvidia.com
Subject: Re: [PATCH V1 rdma-next 04/15] RDMA/umem: Reuse ib_umem_get_cq_buf_or_va() for VA-only CQ pinning
Date: Sun, 20 Sep 2026 15:24:11 +0300 [thread overview]
Message-ID: <20260920122411.GB563127@unreal> (raw)
In-Reply-To: <20260915140933.40580-5-yishaih@nvidia.com>
On Tue, Sep 15, 2026 at 05:09:22PM +0300, Yishai Hadas wrote:
> Several drivers pin their CQ ring buffer via ib_umem_get_va() rather
> than the CQ-specific helper. Switch them to ib_umem_get_cq_buf_or_va()
> so the subsequent DMA_FROM_DEVICE change covers all CQ paths at once.
>
> For shared helpers used by both CQ and non-CQ callers (qedr, mana,
> erdma, hns) a new is_cq parameter selects the appropriate pinning
> function; non-CQ callers pass false.
>
> vmw_pvrdma's CQ is excluded: it embeds a ring-state header that the
> driver CPU-writes after polling, making it genuinely bidirectional.
>
> This is a pure refactor with no functional change.
>
> Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
> ---
> drivers/infiniband/hw/bnxt_re/ib_verbs.c | 9 ++++----
> drivers/infiniband/hw/erdma/erdma_verbs.c | 17 +++++++++-----
> drivers/infiniband/hw/hns/hns_roce_cq.c | 2 +-
> drivers/infiniband/hw/hns/hns_roce_device.h | 2 +-
> drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 2 +-
> drivers/infiniband/hw/hns/hns_roce_mr.c | 22 +++++++++++++-----
> drivers/infiniband/hw/hns/hns_roce_qp.c | 2 +-
> drivers/infiniband/hw/hns/hns_roce_srq.c | 4 ++--
> .../infiniband/hw/ionic/ionic_controlpath.c | 5 ++--
> drivers/infiniband/hw/mana/cq.c | 2 +-
> drivers/infiniband/hw/mana/main.c | 9 ++++++--
> drivers/infiniband/hw/mana/mana_ib.h | 2 +-
> drivers/infiniband/hw/mana/qp.c | 9 ++++----
> drivers/infiniband/hw/mana/wq.c | 3 ++-
> drivers/infiniband/hw/mlx4/cq.c | 14 ++++++-----
> drivers/infiniband/hw/mlx5/cq.c | 6 ++---
> drivers/infiniband/hw/qedr/verbs.c | 23 +++++++++++++------
> 17 files changed, 84 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> index ef08d42f377e..7f9aa3620abb 100644
> --- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> +++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> @@ -3749,12 +3749,13 @@ int bnxt_re_resize_cq(struct ib_cq *ibcq, unsigned int cqe,
> if (rc)
> goto fail;
>
> - cq->resize_umem = ib_umem_get_va(&rdev->ibdev, req.cq_va,
> - entries * sizeof(struct cq_base),
> - IB_ACCESS_LOCAL_WRITE);
> + cq->resize_umem = ib_umem_get_cq_buf_or_va(&rdev->ibdev, NULL,
> + req.cq_va,
> + entries * sizeof(struct cq_base),
> + IB_ACCESS_LOCAL_WRITE);
<...>
> index fca2553e47ad..3519b5044e8f 100644
> --- a/drivers/infiniband/hw/erdma/erdma_verbs.c
> +++ b/drivers/infiniband/hw/erdma/erdma_verbs.c
> @@ -828,11 +828,16 @@ static void erdma_destroy_mtt(struct erdma_dev *dev, struct erdma_mtt *mtt)
>
> static int get_mtt_entries(struct erdma_dev *dev, struct erdma_mem *mem,
> u64 start, u64 len, int access, u64 virt,
> - unsigned long req_page_size, bool force_continuous)
> + unsigned long req_page_size, bool force_continuous,
> + bool is_cq)
> {
> int ret = 0;
>
> - mem->umem = ib_umem_get_va(&dev->ibdev, start, len, access);
> + if (is_cq)
> + mem->umem = ib_umem_get_cq_buf_or_va(&dev->ibdev, NULL, start,
> + len, access);
> + else
> + mem->umem = ib_umem_get_va(&dev->ibdev, start, len, access);
Sorry, but this patch doesn't look right to me.
In bnxt_re_resize_cq(), you chose to move away from the ib_umem_get_va()
API, but here you still keep that API because most of its callers are not
CQs. Why is it so important to specify the direction for CQs while QPs
and MRs are left without it?
Thanks
> if (IS_ERR(mem->umem)) {
> ret = PTR_ERR(mem->umem);
> mem->umem = NULL;
> @@ -951,7 +956,7 @@ static int init_user_qp(struct erdma_qp *qp, struct erdma_ucontext *uctx,
>
> ret = get_mtt_entries(qp->dev, &qp->user_qp.sq_mem, va,
> qp->attrs.sq_size << SQEBB_SHIFT, 0, va,
> - (SZ_1M - SZ_4K), true);
> + (SZ_1M - SZ_4K), true, false);
> if (ret)
> return ret;
>
> @@ -960,7 +965,7 @@ static int init_user_qp(struct erdma_qp *qp, struct erdma_ucontext *uctx,
>
> ret = get_mtt_entries(qp->dev, &qp->user_qp.rq_mem, va + rq_offset,
> qp->attrs.rq_size << RQE_SHIFT, 0, va + rq_offset,
> - (SZ_1M - SZ_4K), true);
> + (SZ_1M - SZ_4K), true, false);
> if (ret)
> goto put_sq_mtt;
>
> @@ -1250,7 +1255,7 @@ struct ib_mr *erdma_reg_user_mr(struct ib_pd *ibpd, u64 start, u64 len,
> return ERR_PTR(-ENOMEM);
>
> ret = get_mtt_entries(dev, &mr->mem, start, len, access, virt,
> - SZ_2G - SZ_4K, false);
> + SZ_2G - SZ_4K, false, false);
> if (ret)
> goto err_out_free;
>
> @@ -1931,7 +1936,7 @@ static int erdma_init_user_cq(struct erdma_ucontext *ctx, struct erdma_cq *cq,
>
> ret = get_mtt_entries(dev, &cq->user_cq.qbuf_mem, ureq->qbuf_va,
> ureq->qbuf_len, IB_ACCESS_LOCAL_WRITE,
> - ureq->qbuf_va, SZ_64M - SZ_4K, true);
> + ureq->qbuf_va, SZ_64M - SZ_4K, true, true);
> if (ret)
> return ret;
Thanks
next prev parent reply other threads:[~2026-09-20 12:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 14:09 [PATCH V1 rdma-next 00/15] DMA direction and mlx5 driver correctness fixes Yishai Hadas
2026-09-15 14:09 ` [PATCH V1 rdma-next 01/15] RDMA/erdma: Pin CQ buffer writable to match device DMA write access Yishai Hadas
2026-09-15 14:22 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 02/15] RDMA/hns: " Yishai Hadas
2026-09-15 14:20 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 03/15] RDMA/vmw_pvrdma: Pin QP and SRQ rings " Yishai Hadas
2026-09-15 14:21 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 04/15] RDMA/umem: Reuse ib_umem_get_cq_buf_or_va() for VA-only CQ pinning Yishai Hadas
2026-09-15 14:21 ` sashiko-bot
2026-09-20 12:24 ` Leon Romanovsky [this message]
2026-09-22 7:25 ` Yishai Hadas
2026-09-15 14:09 ` [PATCH V1 rdma-next 05/15] RDMA/umem: Support an explicit DMA direction other than DMA_BIDIRECTIONAL Yishai Hadas
2026-09-15 14:21 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 06/15] RDMA/umem: Map CQ buffers DMA_FROM_DEVICE Yishai Hadas
2026-09-15 14:25 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 07/15] RDMA/umem: Derive DMA direction from IB access flags Yishai Hadas
2026-09-15 14:28 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 08/15] RDMA/mlx5: Fix mlx5_ib_dev_res_init() failure when XRC cap is absent Yishai Hadas
2026-09-15 14:24 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 09/15] RDMA/mlx5: Put resource reference in mlx5_ib_wq_event() Yishai Hadas
2026-09-15 14:25 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 10/15] RDMA/mlx5: Set WQ event handler before firmware RQ insertion Yishai Hadas
2026-09-15 14:30 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 11/15] RDMA/mlx5: Set SRQ event handler before xarray insertion Yishai Hadas
2026-09-15 14:36 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 12/15] RDMA/mlx5: Set RQ event handler for raw-packet QP Yishai Hadas
2026-09-15 14:32 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 13/15] RDMA/mlx5: Set QP event handler before firmware QPC insertion Yishai Hadas
2026-09-15 14:35 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 14/15] RDMA/mlx5: Initialize QP/RQ/SQ resource refcount before publishing it Yishai Hadas
2026-09-15 14:29 ` sashiko-bot
2026-09-15 14:09 ` [PATCH V1 rdma-next 15/15] RDMA/mlx5: Fix signed integer overflow in EQE qp_srq type shift Yishai Hadas
2026-09-15 14:31 ` sashiko-bot
2026-09-28 12:17 ` [PATCH V1 rdma-next 00/15] DMA direction and mlx5 driver correctness fixes Leon Romanovsky
2026-09-28 12:19 ` Leon Romanovsky
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=20260920122411.GB563127@unreal \
--to=leon@kernel.org \
--cc=abhijit.gangurde@amd.com \
--cc=allen.hubbe@amd.com \
--cc=bryan-bt.tan@broadcom.com \
--cc=chengyou@linux.alibaba.com \
--cc=huangjunxian6@hisilicon.com \
--cc=jgg@ziepe.ca \
--cc=kaishen@linux.alibaba.com \
--cc=kalesh-anakkur.purayil@broadcom.com \
--cc=kotaranov@microsoft.com \
--cc=linux-rdma@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=maorg@nvidia.com \
--cc=mkalderon@marvell.com \
--cc=selvin.xavier@broadcom.com \
--cc=tangchengchang@huawei.com \
--cc=vishnu.dasa@broadcom.com \
--cc=yishaih@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox