James Lentini wrote:
+int rdma_cma_init_qp(struct rdma_cma_id *cma_id, struct ib_qp *qp,
+ int qp_access_flags);
+
How will the qp_accesss_flags be implemented in a transport neutral
way? If iWARP doesn't support the ib_access_flags values, a transport
nuetral consumer can't pass them here.
Bah... my bad. I assumed that iWarp had these same flags. The issue is that IB
needs these flags when transitioning the QP to the INIT state, but doesn't know
how to set them until it knows the initiator_depth and responder_resources.
These values aren't supplied until connect() or accept() is called.
One possibility is to provide a CONNECT_PENDING callback to notify the user that
a connection request is ready to complete. Users may post receives to the QP
from this callback. With this callback, the CMA would be responsible for
transitioning the QP to the INIT state. The disadvantage is that the user would
receive two callbacks trying to establish a connection, rather than one.
Can we remove the need for a consumer to call rdma_cma_init_qp all
together? Can we create a QP and move it to the init state when the
consumer creates their rdma_cma_id?
This is a possibility. I was wanting to allow the user to manage their own list
of QPs, but I guess this is still possible with this change. There's still the
issue that the access flags aren't known however. I need to think about this
more. What do others think?
- 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
