[openib-general] RFC: detecting duplicate MAD requests

Sean Hefty sean.hefty at intel.com
Tue Jun 13 14:58:33 PDT 2006


>> Assuming minimal hard-coding of which methods are requests, a client would
>drop
>> only about 1 MAD per method during start-up.
>
>Is this only the new methods which are not hard coded ? Would this
>invoke a timeout (and hopefully retry) ?

We can hard-code existing methods to avoid this problem.  So only unknown
methods would be affected, which would affect user-defined classes more than the
existing classes.

In most cases, I would expect the sender to timeout and retry the request, which
hopefully comes after the request table has been updated.

>> And I
>> would argue that even if a request has been acknowledged, the sender of the
>> request would still need to deal with the case that no response is ever
>> generated.
>
>Are you referring to a request being acknowledged but the response is
>not sent (yet) ?

Yes.

>> My current thoughts on how to handle requests are to time when each request
>MAD
>> is received, and queue it.  Once the queue is full, if another request is
>> received, it would check the MAD at the head of the queue.  If the MAD at the
>> head was older than some selected value (say 20 seconds), it would be bumped
>> from the queue, and the new request would be added to the tail.
>
>For RMPP, this time should start when the last segment is received. Is
>that how you would envision it working ?

Correct.  Part of the motivation here is if a client cannot or will not generate
a response for some reason, we don't want to keep the MAD hanging around
forever.

>I'm also not sure what the right timeout value would be for this. Where
>did 20 seconds come from ?

I just made that up.  Something like this would probably have to be adaptable,
and would likely depend on the size of the fabric.  In most cases, I would guess
that a timeout indicates some sort of error in the client, so I would tend
towards a larger timeout.

- Sean




More information about the general mailing list