[ofa-general] rdma_resolve_route() returning -EINVAL

[Talpey, Thomas]

At 09:24 PM 10/2/2008, Roland Dreier wrote:
>
> > Ok,. I guess that's not obvious from the name, but in particular if it's
> > so important, then why doesn't anyone implement it? It happens pretty
> > much iimmediately on my IB adapter QPs, under what conditions would
> > it be delayed? And since rdma_destroy_qp() is void, how would I know
> > if I call it too early?
>
>The timewait state is just long enough for any packets to drain out of
>the IB fabric -- the IB spec CM chapter has the exact formula, but it's
>going to be very short.
>
>You're allowed to destroy a QP earlier, but you have a remote chance of
>getting into trouble if you reuse the same QP number before any stale
>packets have drained from the fabric.

Makes sense. I am currently using rdma_create_qp(), so the qpnum isn't
in my control I think. I'm a bit more worried about this being more likely
in a wide-area iWARP connection, which some of the grid folks are considering.
OTOH, I don't want to delay connection recovery - I just found and fixed
the source of a 5-second pause! :-)

>
>The issue is more of spec compliance than a likely real-life
>scenario... and as for why no one else is worrying about it, I think
>it's because the only other user of rdma_connect() in the tree is iSER,
>and I guess no one worried too much there.  SRP uses the IB CM directly,
>and waits for timewait exit before calling a connection closed.

I didn't see the SRP timewait behavior, I'll go look again.

Thanks,
Tom.
>
> - R.