Sean Hefty wrote:
librdmacm/man: update man pages to clarify connection request params
I think you have mentioned that some documentation update is planned?
See the man page updates that were made. There may still be some errors
or omissions, but I tried to address Doug's comments.
Looking in the man directory diff between librdmacm 1.0.3 to 1.0.4 I see
that you added description of the conn param fields for UD and CONN in
the man page of rdma_get_cm_event, where some (most) of the CONN params
are also documented in the man pages of rdma_connect and rdma_accept,
does it makes sense to you to have some cleanup here, putting all the
description in one page (eg rdma_get_cm_event) and in the connect and
accept pages point to that page and just state what need to be fill by
each side.
More re conn params, and also following questions I got from people
coding to librdmacm/libibverbs - for CONN the RNR and ACK timeouts are
being set by the core kernel (rdmacm, cm) code. Adding some mentioning
to this at the librdmacm man pages would save the need to explain it to
people again and again, they can be just sent to the manual... would you
prefer some text from me or you can add it?
- param.retry_count is ignored in the passive side rdma-cm code and
the IB cm uses the one present in the req message.
correct - there's a comment in the header file about the passive side
ignoring this value
lets put it also in the man page - ok?
- param.rnr_retry_count is not ignored in the passive side, but from
looking in the code, I was not sure if the value used is the one
present in the req or the one supplied by the passive consumer.
The passive side uses the value from the req. The active side uses the
value from the rep.
I guess this is dictated by the IB spec... oh well, maybe they wanted to
allow for asymmetric routing or app level schemes, let it be, and just
document it - ok?
- param.flow_control is a pure SW field which does not get into the QP
attr. My understanding is that IB RC flow-control means non zero rnr
counter, is this all? if yes, maybe we need to expose only
rnr_retry_count field
It's a property of the HCA, but it's not clear to me at the moment what
a user does with this field.
maybe the design philosophy of the IB spec here was to let the user tell
the HCA "don't send RNR NAK for this QP when there is no RX buffer
posted"? in second thought it does not makes sense, since ACKs are not
optional. Anyway, I prefer to document at the man that this property is
just value being exchanged between the active and passive side and it
does not translate to anything wrt to the HW - what do you think?
Or.
_______________________________________________
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
