[ofa-general] librdmacm feature request

[Doug Ledford]

On Mon, 2007-10-15 at 12:36 -0700, Sean Hefty wrote:
> > 3)  The man pages on rdma_connect() and rdma_accept() aren't really
> > clear on the role of the connection parameters struct that gets passed
> > in.  Specifically, it doesn't say whether or not the initiator_depth and
> > responder_resources in the parm struct present in the listen event are
> > what the other side set, or if they are already swapped to indicate the
> > minimum/maximum that we can set on our side of the connection.  Also,
> 
> I've added documentation regarding initiator_depth and 
> responder_resources, plus fully defined the data carried in rdma_cm_event.
> 
> > the initial message pointer is not detailed.  When we call
> > rdma_accept/rdma_reject, does our parm struct need to have that same
> > pointer?  Do we need to free that mem?  Can we supply a new initial
> > message and not leak the memory associated with the incoming initial
> > message?
> 
> Can you clarify what message you're referring to?  My assumption is 
> rdma_cm_event, but I want to make sure.

No, I'm referring to the private_data pointer.  After looking through
the code, I can tell that on rmda_connect the contents of this pointer
are copied to kernel space prior to the call returning, so it's safe to
be a stack variable.  That wasn't clear.  And when you get a
private_data pointer in the event struct during a connection request
event, then from what I can tell the memory gets freed when you call
rdma_ack_event, this also wasn't clear.  Some libraries have been known
to malloc() memory and pass it to the program and expect the program to
free() it when it's done.

> I should have the documentation updates available for review later today 
> or tomorrow.
> 
> - Sean
-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20071015/18af68e6/attachment.sig>