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

[Fab Tillier]

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

How would you tell the kernel driver that it needs to do both disconnect and flush as a single IOCTL without changing the IOCTL interfaces?  Or do you not count adding new IOCTLs as a change?

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

Yes, absolutely, and this is what I was saying earlier.  Modify when you send the DREQ will break things.

> I think the existing ND provider code is incorrect on this.

No, the ND proxy code will not change the QP state until DREQ or DREP were received (either one), or DREQ timed out.

-Fab