Really it looks as if this check should be predicated on the actual QP
state which we don't seem to have at this time. The CM state also doesn't
seem to be useful as it is already ESTABLISHED in this case.
Any suggestions?
Given the current code, you could transition to RTS before sending the
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.
On Tue, 24 Nov 2009, Sean Hefty wrote:
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
That's what I suspected. I wonder if the connection state isn't set
properly until later? I'm really not sure. Without a kernel debugger
it'll be hard to determine. I guess I can throw some printfs in to track
this down unless there are better suggestions.
Adding some printk's to
On Mon, 9 Nov 2009, Jason Gunthorpe wrote:
On Mon, Nov 09, 2009 at 01:56:49PM -1000, Jeff Roberson wrote:
Is there anything I can do other than restart the discovery and
connection process? Shouldn't we have enough information with the GID to
retain and reroute the connection?
With a GID
Is there an opensource example of using APM? When I call ib_cm_send_lap()
the QP goes to some error state and my connections die. Do I need to set
some QP attributes first? I found a paper that describes the process but
does not contain sample code or any real details.
Sending the LAP/APR only
One more question; I saw librdmacm which looked nice but it does not
support multi-path connections. It would eliminate a lot of code if we
could use this
what are your needs?
Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
Jeff Roberson wrote:
I would want a way to specify the alternate sockaddr with automatic
failover between them. Perhaps with some notification when a failover occured
From your description I still don't see what the alternate address buys you.
As was suggested here, bond two IPoIB devices,
