[openib-general] Re: [PATCH] [CMA] RDMA CM abstraction module
Michael S. Tsirkin
mst at mellanox.co.il
Mon Oct 10 11:07:50 PDT 2005
Quoting Sean Hefty <mshefty at ichips.intel.com>:
> > Wouldnt is be a good idea to start names with rdma_cm
> > or rdma_cma or something like that?
> > For example, rdma_event_type is a bit confusing since this actually only
> > includes CM events. Similiar comments apply to other names.
>
> I had that originally, but changed it. I figured that names like rdma_connect()
> and rdma_listen() were clear enough that they were for connection management.
Yes, fine, but names like rdma_event_type probably do need the prefix,
dont they?
> >>+struct rdma_id;
> >
> > I propose renaming this to rdma_connection or something
> > else more specific than just "id". Makes sense?
>
> I can change this to rdma_cm_id or rdma_cma or something else...
Maybe rdma_connection (these things encapsulate connectin state)?
Or, rdma_sock or rdma_socket, since people are used to the fact that connections
are sockets?
> >>+int rdma_resolve_route(struct rdma_id *id, int timeout_ms);
> >
> > Not sure I understand what this does, since the only extra parameter is
> > timeout_ms.
>
> For IB, this results in a path record query based on the GIDs that were set with
> the rdma_id from rdma_resolve_addr(). The GIDs are in
> rdma_id.route.addr.ibaddr. The output is saved to rdma_id.route.path_rec. My
> intent is to make this call optional in the future.
I was trying to say, why doesnt rdma_connect just do this
transparently? Why do we need a separate call?
> >>+int rdma_create_qp(struct rdma_id *id, struct ib_pd *pd,
> >>+ struct ib_qp_init_attr *qp_init_attr);
> >>+
> >>+void rdma_destroy_qp(struct rdma_id *id);
> >
> > Not sure what the intended usage is.
> > When does the user need to call this?
>
> The CMA needs to associate a QP with the rdma_id, and CMA will transition the QP
> through its connection states. The rdma_create_qp() is called to allocate a QP
> and transition it to the INIT state, so users can post receives to the QP. The
> destroy call is a pass-through call provided simply for symmetry.
What happends on the passive side?
May we need more than one qp per rdma_id?
Or is a new id created each time a connection request arrives?
--
MST
More information about the general
mailing list