On Tue, May 06, 2025 at 10:17:22AM -0300, Jason Gunthorpe wrote: > On Tue, May 06, 2025 at 06:08:59AM -0700, Christoph Hellwig wrote: > > On Mon, Apr 28, 2025 at 03:36:49PM -0400, cel@xxxxxxxxxx wrote: > > > qp_attr.cap.max_rdma_ctxs. The QP's actual Send Queue length is on > > > the order of the sum of qp_attr.cap.max_send_wr and a factor times > > > qp_attr.cap.max_rdma_ctxs. The factor can be up to three, depending > > > on whether MR operations are required before RDMA Reads. > > > > > > This limit is not visible to RDMA consumers via dev->attrs. When the > > > limit is surpassed, QP creation fails with -ENOMEM. For example: > > > > Can we find a way to expose this limit from the HCA drivers and the > > RDMA core? > > Shouldn't it be max_qp_wr? Does that allow for arbitrary combination of different WRs? If so we'd just need a RW API helper to calculate how many WRs it needs for each operation for the given device and flags and compare to that, yes. (unless my memory is rusty, it's been a while since I touched RDMA code)
