[openib-general] RE: cma header - change some things according to the list feedback

Guy German guyg at voltaire.com
Thu Aug 25 08:55:50 PDT 2005


Hi

> > int ib_cma_get_device(struct sockaddr *remote_address,
> > 		      enum ib_qos qos, struct ib_device **device);
> > 
> >
> 
> Who implements this function? It has to be a core (device-independent)
> function, doesn't it? If so what data is it based upon?
> 
> I believe the ultimate answer here is that each IP Interface
> has to be mapped to 0..1 RDMA devices (or put the other way,
> each RDMA device claims exclusive "RDMA enhancement" rights
> for one or more IP interfaces).
> 
> Once that data is linked the above function can be implemented
> by core software or the user. Since it is of general utility
> it definitely makes sense to provide the common function.

This is implemented today in at.c - see resolve_ip().

> > int ib_cma_connect(struct ib_cma_conn *cma_conn,
> > 		   union ib_cma_id *cma_id);
> > 
> >
> 
> What event is generated at the timeout? 

IB_CMA_EVENT_UNREACHABLE. (We can add all the DAPL events but I think 
We should stick with the minimum required)

> Should it be expicitly
> guaranteed that each connect call will ultimate produce exactly
> one callback?

I think thats an implementation issue 

> > ib_cma_sid_listen(struct ib_device *device, struct sockaddr *address,
> > 		      __be64 service_id, void *context,
> > 		      ib_cma_listen_handler cm_listen_handler,
> > 		      union ib_cma_id *cma_id);
> > 
> >
> 
> Because RDMA connections are established over a reliable connection
> there is a distinct need to have some form of throttle control.
> Excess connection requests received will be non-peer-rejected.
> With kDAPL this is controlled by the size of the connection EVD.
> When using a callback what is needed is for the callback function
> to be able to report that it could not accept the connection request
> object -- resulting in a non-peer reject rather than a peer reject.
> To prevent DoS attacks it is essential that this be done as close
> to the driver as possible.

How do you suggest changing the API then ?

> > 
> > /**
> >  * ib_cma_get_src_ip - this function performs "rarp", asynchronicly
> >  *   from cma_id to src ip
> >  * @cma_id: the cma_id will have to include the path data received 
> >  *   in the request handler
> >  * @src_ip: source ip of the initiator
> >  */
> > int ib_cma_get_src_ip(union ib_cma_id *cma_id,
> > 		      ib_cma_rarp_handler rarp_handler,
> > 		      void *context);
> > 
> 
> Or whatever equivalent logic needed to translate the 'cma_id' to the 
> peer's 'src ip'. This is extracting a field for iWARP. 

Thanks,
Guy




More information about the general mailing list