[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