SRP subnet timeout

SRP subnet timeout

[Karandeep Chahal]

Hi All,

I am wondering why SRP REQ CM timeout is "subnet_timeout + 2". What was the
reason behind adding 2 to the subnet timeout? I think it was added by Bart
in commit 4c532d6ce14bb3fb4e1cb2d29fafdd7d6bded51c, but the commit message
does not explain why the 2 is necessary. Would anyone happen to know?

My understanding is that adding 2 causes the CM timeout value to become 
4 times
the subnet_timeout value. Hence, even if you have a reasonable 
subnet_timeout
the CM REQ timeout becomes too high.

Thank
-Karan

Re: SRP subnet timeout

[Bart Van Assche]

On 9/26/19 7:10 AM, Karandeep Chahal wrote:
> I am wondering why SRP REQ CM timeout is "subnet_timeout + 2". What was the
> reason behind adding 2 to the subnet timeout? I think it was added by Bart
> in commit 4c532d6ce14bb3fb4e1cb2d29fafdd7d6bded51c, but the commit message
> does not explain why the 2 is necessary. Would anyone happen to know?
> 
> My understanding is that adding 2 causes the CM timeout value to become 
> 4 times
> the subnet_timeout value. Hence, even if you have a reasonable 
> subnet_timeout
> the CM REQ timeout becomes too high.

Hi Karan,

I think the description of that commit explains why that change has been 
made:

     IB/srp: Make CM timeout dependent on subnet timeout

     For small networks it is safe to reduce the subnet timeout from
     its default value (18 for opensm) to 16. Make the SRP CM timeout
     dependent on the subnet timeout such that decreasing the subnet
     timeout also causes SRP failover and failback to occur faster.

Bart.

Re: SRP subnet timeout

[Karandeep Chahal]

Hi Bart,

I understand that you have made "SRP CM timeout dependent on subnet 
timeout", but my
question is, why did you add "2" to the subnet timeout? How did you come 
up with
this number?

Forgive me but it is not obvious to me after reading the commit message.

Thanks
-Karan

On 9/26/19 10:54 AM, Bart Van Assche wrote:
> On 9/26/19 7:10 AM, Karandeep Chahal wrote:
>> I am wondering why SRP REQ CM timeout is "subnet_timeout + 2". What 
>> was the
>> reason behind adding 2 to the subnet timeout? I think it was added by 
>> Bart
>> in commit 4c532d6ce14bb3fb4e1cb2d29fafdd7d6bded51c, but the commit 
>> message
>> does not explain why the 2 is necessary. Would anyone happen to know?
>>
>> My understanding is that adding 2 causes the CM timeout value to 
>> become 4 times
>> the subnet_timeout value. Hence, even if you have a reasonable 
>> subnet_timeout
>> the CM REQ timeout becomes too high.
>
> Hi Karan,
>
> I think the description of that commit explains why that change has 
> been made:
>
>     IB/srp: Make CM timeout dependent on subnet timeout
>
>     For small networks it is safe to reduce the subnet timeout from
>     its default value (18 for opensm) to 16. Make the SRP CM timeout
>     dependent on the subnet timeout such that decreasing the subnet
>     timeout also causes SRP failover and failback to occur faster.
>
> Bart.

Re: SRP subnet timeout

[Bart Van Assche]

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

On 9/26/19 8:00 AM, Karandeep Chahal wrote:
> I understand that you have made "SRP CM timeout dependent on subnet 
> timeout", but my
> question is, why did you add "2" to the subnet timeout? How did you come 
> up with
> this number?
> 
> Forgive me but it is not obvious to me after reading the commit message.

Hi Karandeep,

I haven't done any kind of deep research to come up with that value. My 
goal was to preserve the CM timeout used by the SRP initiator for the 
default opensm subnet timeout value (18). There may be better choices 
for the SRP CM timeout.

Bart.

Re: SRP subnet timeout

[Karandeep Chahal]

On 9/26/19 11:14 AM, Bart Van Assche wrote:
>
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
> On 9/26/19 8:00 AM, Karandeep Chahal wrote:
>> I understand that you have made "SRP CM timeout dependent on subnet 
>> timeout", but my
>> question is, why did you add "2" to the subnet timeout? How did you 
>> come up with
>> this number?
>>
>> Forgive me but it is not obvious to me after reading the commit message.
>
> Hi Karandeep,
>
> I haven't done any kind of deep research to come up with that value. 
> My goal was to preserve the CM timeout used by the SRP initiator for 
> the default opensm subnet timeout value (18). There may be better 
> choices for the SRP CM timeout.
>
> Bart.

Hi Bart,

My apologies for top-posting.

The problem with adding 2 to SRP CM timeout is that it makes the SRP CM 
timeout value far off the subnet timeout value.
Now you can either have a reasonable subnet timeout value and an 
unreasonable SRP CM timeout value, or an unreasonable subnet timeout and 
a reasonable SRP CM timeout.

-Karan

Re: SRP subnet timeout

[Bart Van Assche]

On 2019-09-26 08:24, Karandeep Chahal wrote:
> The problem with adding 2 to SRP CM timeout is that it makes the SRP CM
> timeout value far off the subnet timeout value.
> Now you can either have a reasonable subnet timeout value and an
> unreasonable SRP CM timeout value, or an unreasonable subnet timeout and
> a reasonable SRP CM timeout.

Hi Karan,

Do you have a proposal for how the SRP initiator driver should be
modified (patch)? After a patch is available the next step is to write a
text that describes why that change will work for all users (patch
description).

Thanks,

Bart.

Re: SRP subnet timeout

[Karandeep Chahal]

On 9/26/19 10:50 PM, Bart Van Assche wrote:
> On 2019-09-26 08:24, Karandeep Chahal wrote:
>> The problem with adding 2 to SRP CM timeout is that it makes the SRP CM
>> timeout value far off the subnet timeout value.
>> Now you can either have a reasonable subnet timeout value and an
>> unreasonable SRP CM timeout value, or an unreasonable subnet timeout and
>> a reasonable SRP CM timeout.
> Hi Karan,
>
> Do you have a proposal for how the SRP initiator driver should be
> modified (patch)? After a patch is available the next step is to write a
> text that describes why that change will work for all users (patch
> description).
>
> Thanks,
>
> Bart.
Hi Bart,

I will come up with a patch/proposal sometime next week. Please stay tuned.

Thanks
-Karan