RE: LID reconfiguration

Sean Hefty
2009-11-24T17:49:09Z

>Thank you. This worked for me. However, there seems to be some kind of
>race when the connection is first set up. On the client if I call
>ib_cm_send_lap() immediately after ib_cm_send_rtu() returns successfully I
>get an EINVAL error. If I delay for one second it works just fine.

ib_cm_send_lap() returning EINVAL should indicate an immediate error, so this
should be an issue with the local side. It sounds like a possible bug in the
code, but I didn't see anything obvious from a quick look at the code.

>According to the spec the passive/server side can not send the lap so I
>can't send it in the rtu handler. Presumably the call fails immediately
>after send_rtu because the server hasn't received that message yet? Is
>this right? Is there a way to do this cleanly without a delay?

I don't know that the code enforces that the passive side not send a LAP, (and
can't think of a reason why the protocol should have such a restriction.) It
may work. But, rather than sending a separate LAP immediately after connecting,
why not include the alternate path in the original REQ?

>I notice that if I create the initial attributes for the connection
>request with an alternate path specified the alt_path_state is still
>MIGRATED when I send rtu. If I load a path after the connection is
>established I can fail back and forth without issue.

Can you clarify this a little more? What specific field are you looking at and
what state are you seeing it set to?