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 <[EMAIL PROTECTED]>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
