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

[Hal Rosenstock]

On Mon, 2004-11-15 at 16:36, Sean Hefty wrote:
> 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.

What does "ready to receive" mean in this context ? Does it mean there
is no matching send if it is a solicited response ?

>   For unsolicited MADs, I don't see a reasonable alternative.

Not sure what you mean by alternative for unsolicited MADs. For
unsolicited MADs, there is only the version/class/method based routing.
If there is no client, the receive is dropped.

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

Yes, I too would view this as a duplication of MAD layer services. 

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

What functionality are you referring to being duplicated ?
Request/response matching with timeouts ? Wouldn't moving RMPP to user
mode be a duplication ? There are certain things in the kernel that
might want to use RMPP.

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

Yes, but there are two types of routing: TID based and
version/class/method based.

-- Hal