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 10:24:44PM +0530, Sriharsha Basavapatna 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.

It's backwards, we expect old kernels to EOPNOTSUPP when presented
with something that only a new kernel understands. Failing that we
expect that userspace knows to never send something new to an old
kernel with a global flag.

> > How does compatablity work here? Old userspace will send a short
> > structure, the new kernel should effectively see 0 at all these fields
> > is that OK? Sizes of 0 sound bad don't they?
>
> New kernel won't even look at the new fields if the DV bit is not set
> in req->comp_mask, since bnxt_re_dv_create_qp() won't be called; i.e
> if the request comes from old userspace.

Ok
 >
> > New userspace will send a long structure and old kernels will ignore
> > the new bits. Is that OK?
>
> Yes, this is ok, since these new fields are added specifically for the
> DV use-case and a new kernel is required for this functionality.

This does not seem OK, but I guess userspace can detect the resp comp mask
and convert it to a failure. It is not following the design pattern.

> > I would expect you to set QP_REQ_MASK_SIZES in the *req* comp_mask. If
> > old kernel then the kernel fails the creation and userspace can do
> > something else.
> >
> > If the userspace passes QP_REQ_MASK_SIZES and the ioctl succeeds then
> > everthing is OK. Delete the comp_maks in the rep structure.
> As decisions are made based on DV bit in comp_mask (explained above),
> this is not needed right?

It is, the point is to have a comp mask in the input saying which
values of the input are populated and need to be processed by the
kernel.

I think it is not a big change from what you have here, just check the
comp_mask and add a global bit that this kernel checks those
comp_masks properly. Ideally audit all the structs and make sure all
comp_masks work right so the bit includes everything.

comp_mask should be checked against the list of bits this kernel
supports and if other bits are set return EOPNOTSUPP.

Jason