[openib-general][PATCH][RFC]: CMA header
Guy German
guyg at voltaire.com
Tue Sep 20 02:49:09 PDT 2005
Roland Dreier wrote:
> This isn't horrible,
Cheers ;)
> but you seem to have ignored most of the
> discussion from last month:
I did not implement yet the functions that were controversial (i.e.
ib_cma_get_device and ib_cma_get_src_ip). I think it is more productive to
discuss those issues over a preliminary implementation.
> > int ib_cma_get_device(struct sockaddr *remote_address,
> > enum ib_qos qos, struct ib_device **device, u8 *port);
>
> How are you dealing with hotplug and object lifetime issues here?
I did not fully understand why the user can't deal with hot unplug, if he follows:
- register as client (implements add and removal functions)
- creates a list of devices
- get a device from the cma (request by ip)
- check the device is valid and appears in its list
- apply a locking/synchronization mechanism between the removal function and the
calls to the verbs.
I guess I am missing something, so I will start a new thread on that issue.
> > int ib_cma_get_src_ip(void *cma_id, ib_cma_addr_handler addr_handler,
> > void *context);
>
> There's no point in making this asynchronous, since we're putting the
> source/dest information in the CM REQ private data.
Do we have to wait to an ibta approval to do this or can this be implemented
right away, in this fashion ?
> > int ib_cma_create_qp(struct ib_pd *pd, u8 port, struct ib_qp **qp,
> > struct ib_qp_init_attr *init_attr);
>
> What's the point of this function?
This function (_in the current implementation_) is sort of "application note" on
what cma consumers need to do. It forces the consumer to use a qp that was
modified to init after creation. Its only 25 lines long, so I thought I can
leave it there even if one chooses not to use it.
If we choose to change the implementation of device retrieval this function
might be useful.
> > int ib_cma_listen(struct ib_device *device, struct sockaddr *address,
> > __be64 service_id, void *context,
> > ib_cma_listen_handler cm_listen_handler,
> > void **cma_id);
>
> A minor point, but there's no need for the service_id parameter.
> We'll just use the sin_port (or sin6_port) member of the sockaddr.
> Similarly struct ib_cma_conn doesn't need the service_id member either.
iSER, today, uses sid of 64bit, other ULP's might use 64bit sid's too, why limit
them to 16 bit ?
Thanks,
Guy
More information about the general
mailing list