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

Jason Gunthorpe
2025-11-19T19:09:20Z

On Wed, Nov 19, 2025 at 09:44:09PM +0530, Sriharsha Basavapatna wrote:
> On Mon, Nov 17, 2025 at 11:03 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:

> > I think this is generally not how things should work..
> >
> > If you want to create enhanced QP/CQ objects then you should use the
> > existing create QP/CQ ioctls and enhance them with a driver specific
> > uverb spec, not special ioctls like this.
> >
> > Certainly new stuff should be broadly avoiding the 'struct
> > bnxt_re_dv_create_qp_req' kind of design pattern in favour of the new
> > ioctl system's finer grained specs.
>
> We chose the new ioctl approach since it provides a simple direct path
> from the bnxt_re library to the driver, without going through
> ibv_cmd_*() and also since there's really no need to have the kernel
> IB objects (ib_cq/ib_qp) for the DV use case. But we will discuss this
> internally and consider redesigning this based on driver specific
> udata, like you are suggesting.

Well, no "simple direct path" is not a criteria we are using here, we
want to see either common infrastructure used and extended or a
devx/fwctl like direct control.

Not an endless stream of driver specific functions that are ill
defines and unreviewable.

> This design was chosen since some of the applications written by our
> customers are already using umem APIs for mlx devices and they wanted
> to use similar code flow with our devices.

Well that's a horrible reason to add something so broken to the kernel
side.

> pinning. We will address your concern by terminating the umem APIs in
> the library and not going to the driver. Later, at the time of
> resource creation (cq/qp) we will pass the address directly like you
> suggested in your next comment below.

That's much better.

Jason