Re: [PATCH 3/3] RDMA/ionic: Support QP transport mode selection in create and modify

[Abhijit Gangurde]

On 5/11/26 18:20, Leon Romanovsky wrote:
> On Thu, Apr 30, 2026 at 06:09:31PM +0530, Abhijit Gangurde wrote:
> > Allow userspace to specify the QP transport mode and number of
> > reorder completion queue paths during QP creation and modification.
> >
> > Extend ionic_qp_req with transport_mode, num_rcq_paths, and
> > ionic_flags fields. The transport mode selects the firmware QP type,
> > ionic_flags are forwarded in the upper bits of priv_flags during
> > QP creation, and num_rcq_paths is passed to firmware during QP
> > modify.
> >
> > Co-developed-by: Allen Hubbe <allen.hubbe@xxxxxxx>
> > Signed-off-by: Allen Hubbe <allen.hubbe@xxxxxxx>
> > Signed-off-by: Abhijit Gangurde <abhijit.gangurde@xxxxxxx>
> > ---
> >   .../infiniband/hw/ionic/ionic_controlpath.c    | 16 +++++++++++-----
> >   drivers/infiniband/hw/ionic/ionic_fw.h         | 18 +++++++++++++++---
> >   drivers/infiniband/hw/ionic/ionic_ibdev.h      |  1 +
> >   include/uapi/rdma/ionic-abi.h                  |  5 ++++-
> >   4 files changed, 31 insertions(+), 9 deletions(-)
> <...>
>
> > +enum ionic_qp_transport_mode {
> > +	IONIC_QPT_TRANSPORT_ROCE_V2 = BIT(0),
> > +	IONIC_QPT_TRANSPORT_MRC = BIT(1),
> > +};
> > +
> >   /* admin queue qp type */
> >   enum ionic_qp_type {
> >   	IONIC_QPT_RC,
> > @@ -228,16 +235,21 @@ enum ionic_qp_type {
> >   	IONIC_QPT_XRC_INI,
> >   	IONIC_QPT_XRC_TGT,
> >   	IONIC_QPT_XRC_SRQ,
> > +	IONIC_QPT_MRC,
> >   };
> >   
> > -static inline int to_ionic_qp_type(enum ib_qp_type type)
> > +static inline int to_ionic_qp_type(enum ib_qp_type type,
> > +				   enum ionic_qp_transport_mode tm)
> >   {
> >   	switch (type) {
> >   	case IB_QPT_GSI:
> >   	case IB_QPT_UD:
> >   		return IONIC_QPT_UD;
> >   	case IB_QPT_RC:
> > -		return IONIC_QPT_RC;
> > +		if (tm == IONIC_QPT_TRANSPORT_MRC)
> > +			return IONIC_QPT_MRC;
> > +		else
> > +			return IONIC_QPT_RC;
> We have historically treated vendor-specific QP types as special cases and
> routed them through IB_QPT_DRIVER.
>
> IB_QPT_RC represents a standard RC QP and is expected to follow the
> specification.
>
> Thanks

Thank you for the feedback.

I agree that IB_QPT_RC should represent a standard RC QP and follow the 
specification. The reorder completion queue in our firmware is 
essentially an extension of the RC transport -- it follows the same 
state machine and connection semantics as RC.

Instead of distinguishing it as a separate QP type at the IB level, I 
can rework this so that the QP is created as a regular IB_QPT_RC and the 
use of a reorder completion queue with the given QP is conveyed to the 
firmware as a flag in the create QP command. This way, the IB core 
continues to treat it as a standard RC QP, and all the existing state 
machine validation and DMAC resolution in the core path work as expected 
without any special casing.

Thanks