>> @@ -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

_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to