On Wed, 2006-03-15 at 15:06 -0800, Sean Hefty wrote:
> Tom Tucker wrote:
> > +struct iw_cm_id {
> > + iw_cm_handler cm_handler; /* client callback function */
> > + void *context; /* context to provide to
> > client cb */
> > + enum iw_cm_state state;
> > + struct ib_device *device;
> > + struct ib_qp *qp; /* If the qp is null, use
> > qp_num */
> > + u32 qp_num;
> > + struct sockaddr_in local_addr;
> > + struct sockaddr_in remote_addr;
> > + u64 provider_id; /* device handle for this
> > conn. */
> > + iw_event_handler event_handler; /* callback for IW CM Provider
> > events */
> > +};
>
> cm_handler and event_handler have almost the same prototype. One's a void
> function, the other returns an int. Can you explain why two callbacks are
> needed?
The iw_event_handler is registered with the provider by the IW CM. The
iw_cm_handler is registerd with the IW CM by the client. So when the
provider generates an event, it is delivered to the event_handler. When
the IW CM generates an event, it is delivered to the cm_handler. I guess
the comments aren't particularly helpful.
>
> Can you also explain what provider_id is and how a user makes use of it? I
> noticed that you added a comment, but it's not clear to me what a user would
> do
> with this identifier.
The provider_id is the 'cookie' generated by the provider that uniquely
identifies this connection and is passed down to the HW by the provider.
The client doesn't use it. BTW, the alternative here is to have a
create_cm_id and destroy_cm_id call in the provider. I opted for the
'cookie'.
Maybe the provider_id and the event_handler should probably be in
private portion of the data structure.
>
> - Sean
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
