[ofa-general] [PATCH 1/5] [uDAPL v2] dapl scm:update max_rdma_read_iov, max_rdma_write_iov EP attributes during query

Davis, Arlin R arlin.r.davis at intel.com
Fri Aug 15 12:39:12 PDT 2008


 

>> @@ -478,6 +478,8 @@ DAT_RETURN dapls_ib_query_hca (
>>  		ep_attr->max_request_iov  = dev_attr.max_sge;
>>  		ep_attr->max_rdma_read_in = dev_attr.max_qp_rd_atom;
>>  		ep_attr->max_rdma_read_out= dev_attr.max_qp_rd_atom;
>> +		ep_attr->max_rdma_read_iov= dev_attr.max_sge;
>> +		ep_attr->max_rdma_write_iov= dev_attr.max_sge;
>>  		dapl_dbg_log (DAPL_DBG_TYPE_UTIL, 
>>  			" query_hca: MAX msg %llu mtu %d dto %d iov %d"
>>  			" rdma i%d,o%d\n", 
>>   
>This breaks iwarp which only allows 1 SGE for the local SGL in an rdma 
>read.  I thought dev.max_qp_rd_atom indicated this value, not 
>max_sge.  
>So either this patch is wrong, or the rdma device attrs need to be 
>enhanced to separate max_read_sge as a stand-alone attr.

max_qp_rd_atom - max number of rdma reads/atomics outstanding 
                 per QP as a target.
max_qp_init_rd_atom - max number of rdma reads/atomics outstanding 
                 per QP as initiator.
max_sge - max number os scatter/gather entries per work request 
          for all work requests other then reliable datagram. 

At the verbs level, there is no separate SGE value provided for 
rdma_reads over other work request types.

The uDAPL socket cm providers only support IB so this is not an issue 
with this patch. However, with uDAPL rdma_cm providers, I guess we 
need to add a device check on this query and return 1 if iWARP. 

Is this an iWARP specification or implementation issue?


-arlin




More information about the general mailing list