On Tue, May 06, 2025 at 06:40:25AM -0700, Christoph Hellwig wrote: > 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? I think it is supposed to be the maximum QP WR depth you can create.. A QP shouldn't behave differently depending on the WR operation, each one takes one WR entry. Chuck do you know differently? Jason
