[ofw] [Fwd: Connection teardown in WinSock Direct and CM relatedquestions]

[Sean Hefty]

>In the the Windows user mode code for Windows Sockets Direct, it sends
>a CM DREQ (ib_cm_dreq) and then just modifies the QP state to error,
>forcing a flush of outstanding work items. Can someone explain this ?
>
>Is this a workaround for a CM issue or the normal way to handle
>connection termination ? Isn't the DREQ guaranteed to either have a DREP
>reply event, or a timeout or error ? Who's responsibility is it to
>assure that the QP is moved to an appropriate state (CM or "user"/ULP) ?

The Windows stack is designed around having the CM perform the QP state
transitions.  The situation that you mentioned above (transitioning the QP into
ERROR when sending the DREQ) can result in a race condition where outstanding
sends *from* the remote side can timeout, even though the data's been received
by the local side (the one disconnecting).

- Sean