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

[Jason Gunthorpe <jgg@ziepe.ca>]

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?
  
>  struct bnxt_re_qp_req {
> @@ -129,11 +133,22 @@ struct bnxt_re_qp_req {
>  	__aligned_u64 qp_handle;
>  	__aligned_u64 comp_mask;
>  	__u32 sq_slots;
> +	__u32 pd_id;
> +	__u32 sq_wqe_sz;
> +	__u32 sq_psn_sz;
> +	__u32 sq_npsn;
> +	__u32 rq_slots;
> +	__u32 rq_wqe_sz;
> +};

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 userspace will send a long structure and old kernels will ignore
the new bits. Is that OK?

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.

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?

Also the old kernels have a bug:

	struct bnxt_re_qp_req ureq;

		if (ib_copy_from_udata(&ureq, udata,  min(udata->inlen, sizeof(ureq))))
			return -EFAULT;

It should have been "ureq = {};". Those sorts of things must be fixed
or this compatability stuff is really broken/security problem! Please
audit all your ib_copy_from_udata()s!!

Jason