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

[Abhijit Gangurde <abhijit.gangurde@amd.com>]

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@amd.com>
>> Signed-off-by: Allen Hubbe <allen.hubbe@amd.com>
>> Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com>
>> ---
>>   .../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