[openib-general] changing a UC QP to support RDMA Write is not working

[Dotan Barak]

Hi.

I'm using Mellanox HCA on a machine with AS4 with kernel 2.6.9-5.ELsmp.
I'm working with gen2 driver, svn revision 4032.

i wrote a test (2 sides) that have the following flow:
common:
	create a UC QP
	modify the QP to RTS (in RESET->INIT: enable RDMA Read)
side A:
	post recv request

common:
	sync with the other side 

side B:
	post send request (RDMA Write with immediate)

Side A:
	poll CQ (here is the bug: there isn't any completion in the CQ)

when i checked the QP context in side A, i noticed that RDMA Write wasn't enabled for this QP.

for RC QP, the test passes.
(even if side B would have post send request with only RDMA Write (without immediate), there will be a failure: the packet will be dropped in the responder QP).


i looked in the file mthca_qp.c and i saw the following code:

if (attr_mask & IB_QP_ACCESS_FLAGS) { 
	/* 
	* Only enable RDMA/atomics if we have responder 
	* resources set to a non-zero value. 
	*/ 
	if (qp->resp_depth) { 
		qp_context->params2 |= 
			cpu_to_be32(attr->qp_access_flags & IB_ACCESS_REMOTE_WRITE ? 
				MTHCA_QP_BIT_RWE : 0); 
		qp_context->params2 |= 
			cpu_to_be32(attr->qp_access_flags & IB_ACCESS_REMOTE_READ ? 
				MTHCA_QP_BIT_RRE : 0); 
		qp_context->params2 |= 
			cpu_to_be32(attr->qp_access_flags & IB_ACCESS_REMOTE_ATOMIC ? 
				MTHCA_QP_BIT_RAE : 0); 
	} 

	qp_param->opt_param_mask |= cpu_to_be32(MTHCA_QP_OPTPAR_RWE | 
		MTHCA_QP_OPTPAR_RRE | 
			MTHCA_QP_OPTPAR_RAE); 

	qp->atomic_rd_en = attr->qp_access_flags; 
}

the value of the attribute resp_depth is being changed (starting) the state INIT->RTR,
but the value of the attribute atomic_rd_en is being changed (starting) the change RESET->INIT.

did anyone see this behaviour too?

thanx
Dotan Barak
Software Verification Engineer
Mellanox Technologies LTD
Tel: +972-4-9097200 Ext: 231 Fax: +972-4-9593245
P.O. Box 86 Yokneam 20692 ISRAEL.
Home: +972-77-8841095  Cell: 052-4222383

[ May the fork be with you ]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051113/fdb49994/attachment.html>