[openib-general] Solicited response with no matching send request

[Sean Hefty]

Hal Rosenstock wrote:

> After Roland's query this AM, I am looking at this some more:
> 
> On Wed, 2004-11-10 at 13:43, Sean Hefty wrote:
> 
>>The second case where I can see this happening is if the client canceled 
>>the send, and I'm not sure that we'd want to give the client an 
>>unmatched response in this case.
> 
> 
> So do we just keep the cancel around for some time period to make sure
> this doesn't occur ? If so, should cancel also have its own timeout or
> should some arbitrary timeout be used to handle this case ? 

My personal take would be to avoid adding that complexity.  E.g. a 
client sends a MAD with TID 5, cancels 5, sends 5, cancels 5, sends 5. 
A response is now received.  What should the MAD layer do?

I don't see issues with silently dropping any MAD that we're not ready 
to receive.  For unsolicited MADs, I don't see a reasonable alternative.

For solicited (response) MADs, I have a hard time seeing why a client 
would ever want an unmatched MAD, unless they're trying to duplicate MAD 
layer functionality higher in the stack.  For user-mode, this may make 
sense, but I'm not convinced that duplicating the request-response 
functionality in user-mode is the best option (versus moving all of RMPP 
to user-mode).

For the sourceforge stack, we handled this by defining "raw" MAD 
services that did nothing other than send/receive MADs.  Clients using a 
raw service were responsible for performing RMPP, request/response 
matching, and handling timeouts.  This worked, but the MAD layer still 
needed to route received MADs to the correct client.

- Sean