Re: [PATCH rdma-next v9 5/5] RDMA/bnxt_re: Direct Verbs: Support CQ and QP verbs

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, Jan 28, 2026 at 11:27:14PM +0530, Sriharsha Basavapatna wrote:
> On Wed, Jan 28, 2026 at 10:24 PM Sriharsha Basavapatna
> <sriharsha.basavapatna@broadcom.com> wrote:
> >
> > On Wed, Jan 28, 2026 at 9:02 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > >
> > > On Tue, Jan 27, 2026 at 04:01:09PM +0530, Sriharsha Basavapatna wrote:
> > >
> > > >  struct bnxt_re_cq_resp {
> > > > @@ -121,6 +124,7 @@ struct bnxt_re_resize_cq_req {
> > > >
> > > >  enum bnxt_re_qp_mask {
> > > >       BNXT_RE_QP_REQ_MASK_VAR_WQE_SQ_SLOTS = 0x1,
> > > > +     BNXT_RE_QP_DV_SUPPORT = 0x2,
> > > >  };
> > >
> > > This is set on the response but there are no new response fields? That seems
> > > backwards?
> > This is set on the response field so that the library can figure out
> > if its request for DV QP creation (set through req->comp_mask), was
> > successfully executed by the kernel driver or not. If there is an
> > older kernel, the resp->comp_mask bit for DV would be 0 and so the new
> > library would know its request failed.
> I will change this to have a separate bit for DV in the response
> comp_mask, instead of reusing the same value from the req comp_mask.
> Is that ok?

No. Do not return anything in the response comp_mask, you must fail
unsupported requests. That is how comp_mask is intended to
work. Userspace uses the uctx to learn if the request can even be
sent.

> > > Also, what is "pd_id"? The other users of pd_id in prior patches seem
> > > to be actual RDMA PDs. Why is something like this being passed here?
> > > The QP already gets a PD from the core interface, why do you need
> > > another pd?
> > Let me take a closer look at this and get back to you.
> Agree, we had this earlier in our design, but it is not needed anymore
> since we are using std QP-extension mechanism now.

Ok great, because you also were not refcounting the PD properly with
that scheme, that is fixed now too.

Jason