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

Hal Rosenstock halr at voltaire.com
Wed Nov 10 12:53:26 PST 2004


On Wed, 2004-11-10 at 13:43, Sean Hefty wrote:
> Hal Rosenstock wrote:
> 
> > Currently if no matching send request is found, the received MAD is
> > freed (around line 1035 of the current mad.c).
> > 
> > In this case, timeout too short, etc., is this the correct behavior ?
> > Or should the receive packet be given to a matching MAD agent with a
> > receive handler (perhaps with a different status) ? The latter would
> > allow for an additional send model for requests which I don't think is
> > supported now at the cost of having the client throw away these receives
> > based on a new status code (perhaps some sort of timeout).
> 
> I think that this is the behavior that you'd want, but I can see your 
> view, and I'm open to changing it.  From a client's perspective, 
> dropping an unmatched MAD keeps the client from having to handle receive 
> MADs without having a send outstanding.  That is, I would think that a 
> client that could make use of this MAD would have to be fairly complex.

I don't know whether the SM or other managers would use this model so
it's just a thought to keep in mind for the future.

> I see a couple of cases where this would happen.  The first is the one 
> you mention, where the timeout was too short.  If the client retries the 
> request, then they would need to deal with an unmatched response coming 
> in before they issued the retry, while the retry is active (where the 
> retry is sent after the received had checked for a match), or after the 
> retry completed (with the need to handle multiple unmatched responses.)
> 
> 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 we would also need to timeout send MAD cancellations (and not
eliminate them totally immediately) so we wouldn't give a receive back
in that case.

-- Hal




More information about the general mailing list