All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Cheng Xu <chengyou@linux.alibaba.com>
Cc: jgg@ziepe.ca, linux-rdma@vger.kernel.org, KaiShen@linux.alibaba.com
Subject: Re: [PATCH for-next v2 1/4] RDMA/erdma: Support non-contiguous kernel QP buffers
Date: Thu, 10 Sep 2026 18:33:51 +0300	[thread overview]
Message-ID: <20260910153351.GU13683@unreal> (raw)
In-Reply-To: <78e1d57a-7c12-482b-c274-2d9c7991ab1a@linux.alibaba.com>

On Wed, Sep 09, 2026 at 02:21:37PM +0800, Cheng Xu wrote:
> 
> 
> On 9/3/26 8:38 PM, Cheng Xu wrote:
> > 
> > 
> > On 9/3/26 5:10 PM, Leon Romanovsky wrote:
> >> On Thu, Aug 27, 2026 at 04:25:20PM +0800, Cheng Xu wrote:
> >>> A single coherent allocation for kernel QP queues can fail for large
> >>> queues when memory is fragmented.
> >>>
> >>> Allocate page-sized coherent buffers and describe them with the existing
> >>> MTT. Keep the userspace QP path unchanged.
> >>>
> >>> Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com>
> >>> ---
> >>>  drivers/infiniband/hw/erdma/erdma_cq.c    |   4 +-
> >>>  drivers/infiniband/hw/erdma/erdma_qp.c    |  38 +++--
> >>>  drivers/infiniband/hw/erdma/erdma_verbs.c | 195 +++++++++++++---------
> >>>  drivers/infiniband/hw/erdma/erdma_verbs.h |  44 ++++-
> >>>  4 files changed, 179 insertions(+), 102 deletions(-)
> >>
> >> <...>
> >>
> 
> <...>
> 
> >>
> >>> +struct erdma_buf_list {
> >>> +	void *buf;
> >>> +	dma_addr_t dma_addr;
> >>> +};
> >>
> >> This struct is very similar to scatter-gather list, why don't you use it
> >> directly?
> > 
> > Good idea. I will use struct scatterlist in the next revision.
> 
> Hi Leon,
> 
> I switched to scatterlist in v3, but Sashiko pointed out an issue with
> using sg_set_buf() and sg_virt() on dma_alloc_coherent() memory [1].
> 
> To handle this correctly, the driver would still need to retain the
> original CPU addresses returned by dma_alloc_coherent(). Using scatterlist
> does not simplify this implementation: we still need separate storage for
> the CPU addresses, and the only scatterlist field we actually need is the
> DMA address. A small structure holding both addresses would therefore be
> simpler.

Sashiko thinks that you are creating SG list to feed it to dma_map_sg()
later which is not. You are using SG as simple database and you will get
iterators for free.

cpu_address = sg_page()
dma_address = sg_dma_address()

Thanks

> 
> I would like to switch back to a small structure holding the CPU and DMA
> addresses in v4. This would keep the implementation simpler while
> preserving the original addresses returned by dma_alloc_coherent().
> 
> [1] https://sashiko.dev/#/patchset/20260908033709.89898-1-chengyou%40linux.alibaba.com
> 
> Thanks,
> Cheng Xu
> 
> 
> > Thanks,
> > Cheng Xu
> > 
> >>
> >> Thanks

  reply	other threads:[~2026-09-10 15:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-27  8:25 [PATCH for-next v2 0/4] RDMA/erdma: Support non-contiguous kernel queue buffers Cheng Xu
2026-08-27  8:25 ` [PATCH for-next v2 1/4] RDMA/erdma: Support non-contiguous kernel QP buffers Cheng Xu
2026-09-03  9:10   ` Leon Romanovsky
2026-09-03 12:38     ` Cheng Xu
2026-09-09  6:21       ` Cheng Xu
2026-09-10 15:33         ` Leon Romanovsky [this message]
2026-09-11  2:41           ` Cheng Xu
2026-08-27  8:25 ` [PATCH for-next v2 2/4] RDMA/erdma: Support non-contiguous kernel CQ buffers Cheng Xu
2026-08-27  8:25 ` [PATCH for-next v2 3/4] RDMA/erdma: Unify userspace and kernel queue buffer management Cheng Xu
2026-09-03  9:12   ` Leon Romanovsky
2026-09-03 12:40     ` Cheng Xu
2026-08-27  8:25 ` [PATCH for-next v2 4/4] RDMA/erdma: Move kernel QP helpers after memory helpers Cheng Xu

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=20260910153351.GU13683@unreal \
    --to=leon@kernel.org \
    --cc=KaiShen@linux.alibaba.com \
    --cc=chengyou@linux.alibaba.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-rdma@vger.kernel.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 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.