[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