[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