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

[Steve Wise]

Davis, Arlin R wrote:
>  
>
>   
>>> @@ -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?
>
>   
iWARP spec.