Fixed checks and warnings in TCP Vegas
Signed-off-by: Suraj Singh <[email protected]>
---
net/ipv4/tcp_vegas.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/tcp_vegas.c b/net/ipv4/tcp_vegas.c
index ee113ff..0f65cbe 100644
--- a/net/ipv4/tcp_vegas.c
+++ b/net/ipv4/tcp_vegas.c
@@ -139,8 +139,7 @@ void tcp_vegas_state(struct sock *sk, u8 ca_state)
}
EXPORT_SYMBOL_GPL(tcp_vegas_state);
-/*
- * If the connection is idle and we are restarting,
+/* If the connection is idle and we are restarting,
* then we don't want to do any Vegas calculations
* until we get fresh RTT samples. So when we
* restart, we reset our Vegas state to a clean
@@ -223,7 +222,7 @@ static void tcp_vegas_cong_avoid(struct sock *sk, u32 ack, u32 acked)
* and the window we would like to have. This quantity
* is the "Diff" from the Arizona Vegas papers.
*/
- diff = tp->snd_cwnd * (rtt-vegas->baseRTT) / vegas->baseRTT;
+ diff = tp->snd_cwnd * (rtt - vegas->baseRTT) / vegas->baseRTT;
if (diff > gamma && tcp_in_slow_start(tp)) {
/* Going too fast. Time to slow down
@@ -237,7 +236,7 @@ static void tcp_vegas_cong_avoid(struct sock *sk, u32 ack, u32 acked)
* truncation robs us of full link
* utilization.
*/
- tp->snd_cwnd = min(tp->snd_cwnd, (u32)target_cwnd+1);
+ tp->snd_cwnd = min(tp->snd_cwnd, (u32)target_cwnd + 1);
tp->snd_ssthresh = tcp_vegas_ssthresh(tp);
} else if (tcp_in_slow_start(tp)) {
@@ -254,8 +253,7 @@ static void tcp_vegas_cong_avoid(struct sock *sk, u32 ack, u32 acked)
* we slow down.
*/
tp->snd_cwnd--;
- tp->snd_ssthresh
- = tcp_vegas_ssthresh(tp);
+ tp->snd_ssthresh = tcp_vegas_ssthresh(tp);
} else if (diff < alpha) {
/* We don't have enough extra packets
* in the network, so speed up.
--
2.7.4
From: Suraj Singh <[email protected]>
Date: Thu, 8 Nov 2018 13:59:52 +0530
> Fixed checks and warnings in TCP Vegas
>
> Signed-off-by: Suraj Singh <[email protected]>
Once again, please explain why you are putting "staging: " into the subject
line of your TCP congestion control patches.
If you do not answer this question and fix your Subject lines, I will
really have no choice but to ignore your submissions as you are
ignoring our feedback.
Thank you.
Hi,
I'm extremely sorry if I have seemed unresponsive to you but it took me a
while to figure out how to respond to threads using the corresponding mail
-id. I think the first two comments that you wrote on my initial patch with
message-id: [email protected] were being
redirected to my spam folder and since I didn't have mutt configured
then, I didn't see them,
The reason I've been prefixing all the subject of my mails with "staging: "
is because I was following Greg Kroah-Hartman's YouTube video on how to
submit your first kernel patch. I didn't realise the significance of using
it and didn't take the time out to understand what it really meant and that
is my bad. I've got clarifications for the same in comments to the patch with
message-id: [email protected]
I think what I will do is first figure out how to use mutt effectively before
sending subsequent patches and emails because all the emails that I have sent
(including this one), I've done so by manually writing git send-mail commands
in response to the corresponding message-id.
Other than unwarranted "staging: " in the subject, are there any other changes
that need to be made before I submit [v3] of the second tcp_westwood patch
([email protected])?
Regards,
Suraj
I don't think you've been getting my emails because I've been sending them
in response to the message-id of my patch.
Here's my last one:
I'm sorry if I have seemed unresponsive to you but it took me a
while to figure out how to respond to threads using the corresponding mail
-id. I think the first two comments that you wrote on my initial patch with
message-id: [email protected] were being
redirected to my spam folder and since I didn't have mutt configured
then, I didn't see them,
The reason I've been prefixing all the subject of my mails with "staging: "
is because I was following Greg Kroah-Hartman's YouTube video on how to
submit your first kernel patch. I didn't realise the significance
of usingit and didn't take the time out to understand what it really meant and that
is my bad. I've got clarifications for the same in comments to the patch with
message-id: trinity-0d747914-3749-46c4-a5e8-fb7141a9b7c2-1541672570683@3c-app-gmx-bs57
Other than unwarranted "staging: " in the subject, are there any other changes
that need to be made before I submit [v3] of the second tcp_westwood patch
([email protected])?
On Thu, Nov 08, 2018 at 10:34:28AM -0800, David Miller wrote:
> From: Suraj Singh <[email protected]>
> Date: Thu, 8 Nov 2018 13:59:52 +0530
>
> > Fixed checks and warnings in TCP Vegas
> >
> > Signed-off-by: Suraj Singh <[email protected]>
>
> Once again, please explain why you are putting "staging: " into the subject
> line of your TCP congestion control patches.
>
> If you do not answer this question and fix your Subject lines, I will
> really have no choice but to ignore your submissions as you are
> ignoring our feedback.
>
> Thank you.
From: Suraj Singh <[email protected]>
Date: Sun, 11 Nov 2018 22:38:54 +0530
> I don't think you've been getting my emails because I've been sending them
> in response to the message-id of my patch.
I got your email, I'm just too busy to reply.