On Wed, 24 Aug 2005, Sean Hefty wrote:
> >With this in mind, I believe that the connection API needs to be > >something more like the following: > > > > rdma_resolve_address(): > > inputs: dest IP address, qos, npaths, > > done callback, opaque context > > done callback params: status, local RDMA device, > > RDMA transport address, context > ... > > rdma_connect(): > > inputs: local QP, RDMA transport address, destination service, > > private data, timeout, event callback, opaque context > > Have we agreed that this is the functionality that we should be > aiming towards? I think so, but as you pointed out the local QP must be in the init state. > > > rdma_resolve_address(...); > > /* wait for resolution */ > > ib_create_qp(...) /* use device pointer we got from > > rdma_resolve_address() > >*/ > > We need to insert in here: > > ib_modify_qp(...); /* somehow uses address resolution... */ > ib_post_recvs(...); > or add a new call to create the qp and modify it to init (an analog to the socket(2) function). > > rdma_connect(...); /* pass transport address we got from > >rdma_resolve_address() */ > > /* wait for connection to finish... */ > > Another possibility could be to add a list of receives to > rdma_connect(). The caller might also want to setup memory windows. Requiring the qp to be in the init state before calling connect seems cleaner to me. > > - Sean > > > _______________________________________________ > openib-general mailing list > [email protected] > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
