[ofw] RE: [PATCH] Support for ND over WV (incomplete)

[Sean Hefty]

>> - We can safely modify the QP state to error when:
>> 	a) a DREQ has been received
>> 	b) a DREP has been received
>> - CM callbacks are at dispatch.
>> - For a) we can modify to error in the downcall from userspace
>>   We just need to know if a DREQ has been received
>>   (Note that all other QP modify calls are done in downcalls.)
>
>Just to clarify, you would do the QP modify only if the DREQ was received, yes?

yes - that's what I meant by 'has been received'  :)

>Yep, this is what's done in the ND proxy code - queue an I/O work item to do
>the QP modification.  It's easy to allocate the work item when the IOCTL first
>comes down, to eliminate the risk of allocation failure in the CM callback, if
>desired.
>
>Did I ever send my patch to change WvQpModify to be async?  It used an I/O work
>item to delay the QP modification.  A similar technique could be used in the
>DisconnectAndFlush case.

You posted those changes, and that's what I was thinking of.

>I think handling it in the kernel is preferable to having an extra thread per
>process in the ND provider just to handle disconnection. 

This is one point for the kernel.  I'm keeping score

>If you don't want threads in the ND provider, you have to do this via an
>IOCTL/API change.   The completion of the disconnect gets reported to the user,
>you have no opportunity to intercept and issue flush the QP.

The driver may need to change, but the API/IOCTL interfaces should still be
sufficient. 

>The third way would be to do a synchronous disconnect followed by an
>asynchronous QP modify (but that too is handled synchronously in the existing

I don't think this works.  You can't do the modify until either a DREQ or DREP
have been *received*, not sent.  I think the existing ND provider code is
incorrect on this.

>From the perspective of a winverbs user, QP modify needs to occur after
NotifyDisconnect completes.

- Sean