[ofw] [PATCH] dapl: use private_data_len for mem copies

[Sean Hefty]

>ok, given there is no single protocol and you define different
>absolute max values (56 on Windows, 256 on Linux), how
>do rdma_cm consumer's authenticate private data capabilities?

The private data differs based the underlying transport, connection message,
implementation, and, possibly someday, the underlying link.  The guaranteed
*minimum* for any message/transport/implementation is 0.  :)  There is no
guarantee on the maximum.

For standard IB, if the RDMA IP CM service is employeed, 56 bytes are currently
available in the REQ (rdma_connect() call).  Other messages and functions,
rdma_accept() and rdma_reject(), are higher.  If the UDP port space is used
instead of the TCP port space, then 180 bytes are available when calling
rdma_connect().  If SDP is employeed, 28 bytes are available in the REQ.  Future
extensions to the RDMA CM, such as IB ACM support may adjust these values -- in
this case, it could be more.  So, even with IB there is not one correct value.

The rdma_cm could expose a new call that would return the guaranteed maximum
size of private data for a specific rdma_cm_id based on its state, but this
doesn't really help DAPL, which is wanting to report one value for the device
that is guaranteed to work for any call.

- Sean