[ofa-general] librdmacm 1.0.4 release

[Or Gerlitz]

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.