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

[Hal Rosenstock]

On Mon, 2008-03-10 at 12:58 -0700, Sean Hefty wrote:
> >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.

Do you know if the Windows CM implementation matches this design ?

> 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).

So sounds like that workaround in WinSock direct should be removed
then ?

-- Hal

> - Sean
>