From: Stephen Hemminger <stephen@networkplumber.org>
To: Neal Cardwell <ncardwell@google.com>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, Van Jacobson <vanj@google.com>,
Yuchung Cheng <ycheng@google.com>,
Nandita Dukkipati <nanditad@google.com>,
Eric Dumazet <edumazet@google.com>,
Soheil Hassas Yeganeh <soheil@google.com>
Subject: Re: [PATCH v3 net-next 16/16] tcp_bbr: add BBR congestion control
Date: Mon, 19 Sep 2016 13:57:34 -0700 [thread overview]
Message-ID: <20160919135734.04ab5172@xeon-e3> (raw)
In-Reply-To: <1474236233-28511-17-git-send-email-ncardwell@google.com>
On Sun, 18 Sep 2016 18:03:53 -0400
Neal Cardwell <ncardwell@google.com> wrote:
> +static int bbr_bw_rtts = CYCLE_LEN + 2; /* win len of bw filter (in rounds) */
> +static u32 bbr_min_rtt_win_sec = 10; /* min RTT filter window (in sec) */
> +static u32 bbr_probe_rtt_mode_ms = 200; /* min ms at cwnd=4 in BBR_PROBE_RTT */
> +static int bbr_min_tso_rate = 1200000; /* skip TSO below here (bits/sec) */
> +
> +/* We use a high_gain value chosen to allow a smoothly increasing pacing rate
> + * that will double each RTT and send the same number of packets per RTT that
> + * an un-paced, slow-starting Reno or CUBIC flow would.
> + */
> +static int bbr_high_gain = BBR_UNIT * 2885 / 1000 + 1; /* 2/ln(2) */
> +static int bbr_drain_gain = BBR_UNIT * 1000 / 2885; /* 1/high_gain */
> +static int bbr_cwnd_gain = BBR_UNIT * 2; /* gain for steady-state cwnd */
> +/* The pacing_gain values for the PROBE_BW gain cycle: */
> +static int bbr_pacing_gain[] = { BBR_UNIT * 5 / 4, BBR_UNIT * 3 / 4,
> + BBR_UNIT, BBR_UNIT, BBR_UNIT,
> + BBR_UNIT, BBR_UNIT, BBR_UNIT };
> +static u32 bbr_cycle_rand = 7; /* randomize gain cycling phase over N phases */
> +
> +/* Try to keep at least this many packets in flight, if things go smoothly. For
> + * smooth functioning, a sliding window protocol ACKing every other packet
> + * needs at least 4 packets in flight.
> + */
> +static u32 bbr_cwnd_min_target = 4;
> +
> +/* To estimate if BBR_STARTUP mode (i.e. high_gain) has filled pipe. */
> +static u32 bbr_full_bw_thresh = BBR_UNIT * 5 / 4; /* bw up 1.25x per round? */
> +static u32 bbr_full_bw_cnt = 3; /* N rounds w/o bw growth -> pipe full */
> +
> +/* "long-term" ("LT") bandwidth estimator parameters: */
> +static bool bbr_lt_bw_estimator = true; /* use the long-term bw estimate? */
> +static u32 bbr_lt_intvl_min_rtts = 4; /* min rounds in sampling interval */
> +static u32 bbr_lt_loss_thresh = 50; /* lost/delivered > 20% -> "lossy" */
> +static u32 bbr_lt_conv_thresh = BBR_UNIT / 8; /* bw diff <= 12.5% -> "close" */
> +static u32 bbr_lt_bw_max_rtts = 48; /* max # of round trips using lt_bw */
> +
Looks good, but could I suggest a simple optimization.
All these parameters are immutable in the version of BBR you are submitting.
Why not make the values const? And eliminate the always true long-term bw estimate
variable?
diff --git a/net/ipv4/tcp_bbr.c b/net/ipv4/tcp_bbr.c
index 76baa8a..9c270a2 100644
--- a/net/ipv4/tcp_bbr.c
+++ b/net/ipv4/tcp_bbr.c
@@ -90,40 +90,41 @@ struct bbr {
#define CYCLE_LEN 8 /* number of phases in a pacing gain cycle */
-static int bbr_bw_rtts = CYCLE_LEN + 2; /* win len of bw filter (in rounds) */
-static u32 bbr_min_rtt_win_sec = 10; /* min RTT filter window (in sec) */
-static u32 bbr_probe_rtt_mode_ms = 200; /* min ms at cwnd=4 in BBR_PROBE_RTT */
-static int bbr_min_tso_rate = 1200000; /* skip TSO below here (bits/sec) */
+static const int bbr_bw_rtts = CYCLE_LEN + 2; /* win len of bw filter (in rounds) */
+static const u32 bbr_min_rtt_win_sec = 10; /* min RTT filter window (in sec) */
+static const u32 bbr_probe_rtt_mode_ms = 200; /* min ms at cwnd=4 in BBR_PROBE_RTT */
+static const int bbr_min_tso_rate = 1200000; /* skip TSO below here (bits/sec) */
/* We use a high_gain value chosen to allow a smoothly increasing pacing rate
* that will double each RTT and send the same number of packets per RTT that
* an un-paced, slow-starting Reno or CUBIC flow would.
*/
-static int bbr_high_gain = BBR_UNIT * 2885 / 1000 + 1; /* 2/ln(2) */
-static int bbr_drain_gain = BBR_UNIT * 1000 / 2885; /* 1/high_gain */
-static int bbr_cwnd_gain = BBR_UNIT * 2; /* gain for steady-state cwnd */
+static const int bbr_high_gain = BBR_UNIT * 2885 / 1000 + 1; /* 2/ln(2) */
+static const int bbr_drain_gain = BBR_UNIT * 1000 / 2885; /* 1/high_gain */
+static const int bbr_cwnd_gain = BBR_UNIT * 2; /* gain for steady-state cwnd */
/* The pacing_gain values for the PROBE_BW gain cycle: */
-static int bbr_pacing_gain[] = { BBR_UNIT * 5 / 4, BBR_UNIT * 3 / 4,
- BBR_UNIT, BBR_UNIT, BBR_UNIT,
- BBR_UNIT, BBR_UNIT, BBR_UNIT };
-static u32 bbr_cycle_rand = 7; /* randomize gain cycling phase over N phases */
+static const int bbr_pacing_gain[] = {
+ BBR_UNIT * 5 / 4, BBR_UNIT * 3 / 4,
+ BBR_UNIT, BBR_UNIT, BBR_UNIT,
+ BBR_UNIT, BBR_UNIT, BBR_UNIT
+};
+static const u32 bbr_cycle_rand = 7; /* randomize gain cycling phase over N phases */
/* Try to keep at least this many packets in flight, if things go smoothly. For
* smooth functioning, a sliding window protocol ACKing every other packet
* needs at least 4 packets in flight.
*/
-static u32 bbr_cwnd_min_target = 4;
+static const u32 bbr_cwnd_min_target = 4;
/* To estimate if BBR_STARTUP mode (i.e. high_gain) has filled pipe. */
-static u32 bbr_full_bw_thresh = BBR_UNIT * 5 / 4; /* bw up 1.25x per round? */
-static u32 bbr_full_bw_cnt = 3; /* N rounds w/o bw growth -> pipe full */
+static const u32 bbr_full_bw_thresh = BBR_UNIT * 5 / 4; /* bw up 1.25x per round? */
+static const u32 bbr_full_bw_cnt = 3; /* N rounds w/o bw growth -> pipe full */
/* "long-term" ("LT") bandwidth estimator parameters: */
-static bool bbr_lt_bw_estimator = true; /* use the long-term bw estimate? */
-static u32 bbr_lt_intvl_min_rtts = 4; /* min rounds in sampling interval */
-static u32 bbr_lt_loss_thresh = 50; /* lost/delivered > 20% -> "lossy" */
-static u32 bbr_lt_conv_thresh = BBR_UNIT / 8; /* bw diff <= 12.5% -> "close" */
-static u32 bbr_lt_bw_max_rtts = 48; /* max # of round trips using lt_bw */
+static const u32 bbr_lt_intvl_min_rtts = 4; /* min rounds in sampling interval */
+static const u32 bbr_lt_loss_thresh = 50; /* lost/delivered > 20% -> "lossy" */
+static const u32 bbr_lt_conv_thresh = BBR_UNIT / 8; /* bw diff <= 12.5% -> "close" */
+static const u32 bbr_lt_bw_max_rtts = 48; /* max # of round trips using lt_bw */
/* Do we estimate that STARTUP filled the pipe? */
static bool bbr_full_bw_reached(const struct sock *sk)
@@ -470,8 +471,7 @@ static void bbr_lt_bw_interval_done(struct sock *sk, u32 bw)
struct bbr *bbr = inet_csk_ca(sk);
u32 diff;
- if (bbr->lt_bw && /* do we have bw from a previous interval? */
- bbr_lt_bw_estimator) { /* using long-term bw estimator enabled? */
+ if (bbr->lt_bw) { /* do we have bw from a previous interval? */
/* Is new bw close to the lt_bw from the previous interval? */
diff = abs(bw - bbr->lt_bw);
if ((diff * BBR_UNIT <= bbr_lt_conv_thresh * bbr->lt_bw) ||
next prev parent reply other threads:[~2016-09-19 20:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-18 22:03 [PATCH v3 net-next 00/16] tcp: BBR congestion control algorithm Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 01/16] tcp: cdg: rename struct minmax in tcp_cdg.c to avoid a naming conflict Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 02/16] lib/win_minmax: windowed min or max estimator Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 03/16] tcp: use windowed min filter library for TCP min_rtt estimation Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 04/16] net_sched: sch_fq: add low_rate_threshold parameter Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 05/16] tcp: switch back to proper tcp_skb_cb size check in tcp_init() Neal Cardwell
2016-09-19 14:37 ` Lance Richardson
2016-09-19 14:41 ` Eric Dumazet
2016-09-18 22:03 ` [PATCH v3 net-next 06/16] tcp: count packets marked lost for a TCP connection Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 07/16] tcp: track data delivery rate " Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 08/16] tcp: track application-limited rate samples Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 09/16] tcp: export data delivery rate Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 10/16] tcp: allow congestion control module to request TSO skb segment count Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 11/16] tcp: export tcp_tso_autosize() and parameterize minimum number of TSO segments Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 12/16] tcp: export tcp_mss_to_mtu() for congestion control modules Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 13/16] tcp: allow congestion control to expand send buffer differently Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 14/16] tcp: new CC hook to set sending rate with rate_sample in any CA state Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 15/16] tcp: increase ICSK_CA_PRIV_SIZE from 64 bytes to 88 Neal Cardwell
2016-09-18 22:03 ` [PATCH v3 net-next 16/16] tcp_bbr: add BBR congestion control Neal Cardwell
[not found] ` <CA++eYdtWkMqT1zk_D00H1TciYb_4+aQ6-96YzG1n_h4LLk663g@mail.gmail.com>
2016-09-19 2:43 ` Neal Cardwell
2016-09-19 20:57 ` Stephen Hemminger [this message]
2016-09-19 21:10 ` Eric Dumazet
2016-09-19 21:17 ` Rick Jones
2016-09-19 21:23 ` Eric Dumazet
2016-09-19 23:28 ` Stephen Hemminger
2016-09-19 23:33 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160919135734.04ab5172@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=nanditad@google.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=soheil@google.com \
--cc=vanj@google.com \
--cc=ycheng@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.