[openib-general] Re: queue pair destruction on dat_ep_disconnect
mark kowalski
mkowalski01 at gmail.com
Mon Mar 21 09:23:45 PST 2005
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
More information about the general
mailing list