I guess "queue pair destruction" was a poor choice of words. What I meant was the freeing/cleaning up of the dapl structures that connect to the queue pair, not the actual queue pair itself. Sorry about that.
Anyway, about the single EP on a machine. All I can do is report what I'm seeing. It doesn't make any sense to me either, but that is what's happening. Also, It is not the dat_ep_create that fails, it is the subsequent incoming connect request that would fail. Sorry if I was unclear about that. Thanks, Mark >May I point out that taking your analysis to its logical conclusion, you could only ever have >a single EP on any machine if each EP has a unique QP. This is obviously false, I think >you're looking in the wrong place. >dat_ep_disconnect() is not supposed to destroy a QP, just transition the state to a not->connected state (IB state ERROR). An EP, and by extension a QP, can have several >different attributes, it wouldn't be efficient or intuitive if you destroyed the underlying QP >just because you are disconnecting. The QP remains attached to the EP until you >explicitly free it in dat_ep_free(); this is intentional and by design. >If you look at the state diagram in the DAT spec, you will notice that you should >dat_ep_reset() the EP before you try to use it again. This will transition the underlying >QP from the ERROR state to INIT. But I don't think you're trying to reuse the EP, so I don't >know why it's a problem. >Getting back to your real problem, I'm not sure why you can't create a new EP on a >different IA, they should be completely separate. If dat_ep_create() fails, something is >hosed. I don't know about the destroy_cbk field as it isn't in the reference >implementation, so I can't help you there. >-Steve _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
