[PATCH] mptcp: using TOKEN_MAX_RETRIES instead of magic number

[PATCH] mptcp: using TOKEN_MAX_RETRIES instead of magic number

[Jianguo Wu]

From: Jianguo Wu <wujianguo@chinatelecom.cn>

We have macro TOKEN_MAX_RETRIES for the number of token generate retries,
so using TOKEN_MAX_RETRIES in subflow_check_req().

Fixes: 535fb8152f31 ("mptcp: token: move retry to caller")
Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
---
 net/mptcp/protocol.h | 2 ++
 net/mptcp/subflow.c  | 2 +-
 net/mptcp/token.c    | 1 -
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index abd8e31..88f1e2b 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -14,6 +14,8 @@

 #define MPTCP_SUPPORTED_VERSION	1

+#define TOKEN_MAX_RETRIES	4
+
 /* MPTCP option bits */
 #define OPTION_MPTCP_MPC_SYN	BIT(0)
 #define OPTION_MPTCP_MPC_SYNACK	BIT(1)
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 325ea7e..977a848 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -162,7 +162,7 @@ static int subflow_check_req(struct request_sock *req,
 	}

 	if (mp_opt.mp_capable && listener->request_mptcp) {
-		int err, retries = 4;
+		int err, retries = TOKEN_MAX_RETRIES;

 		subflow_req->ssn_offset = TCP_SKB_CB(skb)->seq;
 again:
diff --git a/net/mptcp/token.c b/net/mptcp/token.c
index 72a24e6..555c962 100644
--- a/net/mptcp/token.c
+++ b/net/mptcp/token.c
@@ -33,7 +33,6 @@
 #include <net/mptcp.h>
 #include "protocol.h"

-#define TOKEN_MAX_RETRIES	4
 #define TOKEN_MAX_CHAIN_LEN	4

 struct token_bucket {
-- 
1.8.3.1

Re: [PATCH] mptcp: using TOKEN_MAX_RETRIES instead of magic number

[Matthieu Baerts]

Hi Jianguo,

Thank you for the patch!

On 21/04/2021 09:36, Jianguo Wu wrote:
> From: Jianguo Wu <wujianguo@chinatelecom.cn>
> 
> We have macro TOKEN_MAX_RETRIES for the number of token generate retries,
> so using TOKEN_MAX_RETRIES in subflow_check_req().
> 
> Fixes: 535fb8152f31 ("mptcp: token: move retry to caller")
> Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
> ---
>  net/mptcp/protocol.h | 2 ++
>  net/mptcp/subflow.c  | 2 +-
>  net/mptcp/token.c    | 1 -
>  3 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
> index abd8e31..88f1e2b 100644
> --- a/net/mptcp/protocol.h
> +++ b/net/mptcp/protocol.h
> @@ -14,6 +14,8 @@
> 
>  #define MPTCP_SUPPORTED_VERSION	1
> 
> +#define TOKEN_MAX_RETRIES	4

Now that this is "exposed" in a header file, probably best to rename it
to add "MPTCP_" suffix like (most of) the others here.

Also maybe best to declare it around where the token related functions
are declared, no? In other words, just before mptcp_token_init().

Or after the other "#define" we have here but it looks strange to put
this at before them.

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

Re: [PATCH] mptcp: using TOKEN_MAX_RETRIES instead of magic number

[Jianguo Wu]

On 2021/4/21 16:23, Matthieu Baerts wrote:
> Hi Jianguo,
> 
> Thank you for the patch!
> 
> On 21/04/2021 09:36, Jianguo Wu wrote:
>> From: Jianguo Wu <wujianguo@chinatelecom.cn>
>>
>> We have macro TOKEN_MAX_RETRIES for the number of token generate retries,
>> so using TOKEN_MAX_RETRIES in subflow_check_req().
>>
>> Fixes: 535fb8152f31 ("mptcp: token: move retry to caller")
>> Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
>> ---
>>  net/mptcp/protocol.h | 2 ++
>>  net/mptcp/subflow.c  | 2 +-
>>  net/mptcp/token.c    | 1 -
>>  3 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
>> index abd8e31..88f1e2b 100644
>> --- a/net/mptcp/protocol.h
>> +++ b/net/mptcp/protocol.h
>> @@ -14,6 +14,8 @@
>>
>>  #define MPTCP_SUPPORTED_VERSION	1
>>
>> +#define TOKEN_MAX_RETRIES	4
> 
> Now that this is "exposed" in a header file, probably best to rename it
> to add "MPTCP_" suffix like (most of) the others here.
> 
> Also maybe best to declare it around where the token related functions
> are declared, no? In other words, just before mptcp_token_init().
> 
> Or after the other "#define" we have here but it looks strange to put
> this at before them.
> 

Hi Matt, I will send v2 as your suggestion, Thanks!

> Cheers,
> Matt
>