[ofa-general] librdmacm 1.0.4 release

[Sean Hefty]

> 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