From: Rick Jones <rick.jones2@hp.com>
To: netdev@vger.kernel.org
Subject: is non-inheritance of congestion control algorithm from the listen socket a bug or a feature?
Date: Tue, 29 Nov 2011 12:03:45 -0800 [thread overview]
Message-ID: <4ED53AA1.9090800@hp.com> (raw)
Dave Taht asked me if I would consider adding control/reporting of the
congestion control algorithm to netperf. I'm in the midst of doing that
and have noticed that setting a valid congestion control algorithm on a
listen endpoint does not seem to be inherited by subsequent connections.
Rather than rely on netperf/netserver I cobbled-together a quick test
program to show what I mean.
raj@raj-ubuntu-guest:~$ uname -a
Linux raj-ubuntu-guest 3.2.0-rc2+ #1 SMP Mon Nov 28 16:39:21 PST 2011
x86_64 x86_64 x86_64 GNU/Linux
raj@raj-ubuntu-guest:~$ find /proc -name "*cong*" -print -exec cat {} \;
2>/dev/null
/proc/sys/net/ipv4/tcp_congestion_control
cubic
/proc/sys/net/ipv4/tcp_available_congestion_control
cubic reno
/proc/sys/net/ipv4/tcp_allowed_congestion_control
cubic reno
# first just report what one gets
raj@raj-ubuntu-guest:~$ ./tcp_congestion_test
Will make no request to set congestion control algorithm
active socket has '' for congestion control
passive socket has '' for congestion control
after listen() passive socket has '' for congestion control
after connect() active has 'cubic' for congestion control
after accept() accepted has 'cubic' for congestion control
# now specify a valid alternative
raj@raj-ubuntu-guest:~$ ./tcp_congestion_test reno
Will be requesting 'reno' as the congestion control algorithm
active socket has 'reno' for congestion control
passive socket has 'reno' for congestion control
after listen() passive socket has 'reno' for congestion control
after connect() active has 'reno' for congestion control
after accept() accepted has 'cubic' for congestion control
# now specify an invalid alternative just for completeness
raj@raj-ubuntu-guest:~$ ./tcp_congestion_test bogus
Will be requesting 'bogus' as the congestion control algorithm
active socket has '' for congestion control
passive socket has '' for congestion control
after listen() passive socket has '' for congestion control
after connect() active has 'cubic' for congestion control
after accept() accepted has 'cubic' for congestion control
Is the non-inheritance of the congestion control algorithm a bug or a
feature?
rick jones
next reply other threads:[~2011-11-29 20:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-29 20:03 Rick Jones [this message]
2011-11-29 20:27 ` is non-inheritance of congestion control algorithm from the listen socket a bug or a feature? Dave Taht
2011-11-29 20:56 ` Eric Dumazet
2011-11-29 21:17 ` Rick Jones
2011-11-29 21:20 ` Yuchung Cheng
2011-11-29 21:46 ` Eric Dumazet
2011-11-29 21:52 ` David Miller
2011-11-29 21:56 ` Eric Dumazet
2011-11-29 22:01 ` Stephen Hemminger
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=4ED53AA1.9090800@hp.com \
--to=rick.jones2@hp.com \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).