[ofa-general] Re: setting iWarp IRD and ORD

[Kanevsky, Arkady]

And what happens when RNIC on two sides have a different upper limits?
Specifically, if requestor asks for ORD which is bigger than responder
can handle?
Is it user responsibility to pass ORD request out of bound to responder
and
if responder can not satisfy it then reject the request?
Thanks,
 

Arkady Kanevsky                       email: arkady at netapp.com

Network Appliance Inc.               phone: 781-768-5395

1601 Trapelo Rd. - Suite 16.        Fax: 781-895-1195

Waltham, MA 02451                   central phone: 781-768-5300

 


________________________________

	From: Steve Wise [mailto:swise at opengridcomputing.com] 
	Sent: Thursday, January 03, 2008 9:42 PM
	To: Sean Hefty
	Cc: OpenFabrics General
	Subject: [ofa-general] Re: setting iWarp IRD and ORD
	
	


	Sean Hefty wrote: 

			What exactly are you fixing?
			    

		
		It may help to look at the patch for the librdmacm that
I just posted.  The
		problem that was seen was that uDAPL set IRD/ORD to 16
in the connection
		request, but the passive side could only support 4.  The
rdma_cm was supposed to
		use the lower value (provided by the user when calling
rdma_accept) when
		transitioning the QP, but instead used the value from
the request.
		
		Since iWarp connect request doesn't carry the IRD/ORD
and always uses the value
		provided by the user through rdma_connect or
rdma_accept, it doesn't sound like
		it would hit this problem.  I just don't quite follow
why
		iwcm_init_qp_rts_attr() doesn't set the QP attribute
mask for IRD/ORD, or how
		the QP is programmed with these values.
		
		  

	Perhaps this is a bug.  But the chelsio driver just saves off
the ord/ird from the connection parameters and then programs the qp with
these values when the qp is associated with the connection (just after
the connection goes into rdma mode)...
	
	

		- Sean
		  



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