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.
The text is slightly different in places depending on the context.
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?
I don't understand the source of the confusion yet. The values that are
used are based on what's passed in by the user. All QP attributes are
set by the kernel code when it's modified by the library.
- 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?
Yes - rdma_accept man page has been updated (not pushed yet) to indicate
that this value is ignored.
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?
The rdma_connect and rdma_accept man pages have been updated to state
that rnr_retry_count value applies to the remote peer.
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?
I will see if I can come up with something useful to say here.
- Sean
_______________________________________________
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
