tcp_bic (was Re: 2.6.12-rc6-mm1 OOPS in tcp_push_one()

[Valdis.Kletnieks@vt.edu]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

On Wed, 08 Jun 2005 22:58:17 PDT, "David S. Miller" said:
> From: Valdis.Kletnieks@vt.edu
> Date: Thu, 09 Jun 2005 00:23:32 -0400
> 
> > (On a related note, how did tcp_bic get loaded? I requested all the new
> > congestion stuff be built as modules, didn't specifically request any of
> > them to actually be loaded....
> 
> It's the default algorithm, so when you open the first TCP
> socket it tries to load it.

Ahh.. I was reading the Kconfig, which says this:

menu "TCP congestion control"
# TCP Reno is builtin (required as fallback)
        
config TCP_CONG_BIC
        tristate "Binary Increase Congestion (BIC) control"
        depends on INET
        default y

and I built with:

CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m

so what I *expected* was a kernel with Reno built-in, and the others as
modules if I got ambitious and loaded one or another.

How do people feel about this:

--- linux-2.6.12-rc6-mm1/net/ipv4/Kconfig.bic	2005-06-07 12:55:41.000000000 -0400
+++ linux-2.6.12-rc6-mm1/net/ipv4/Kconfig	2005-06-09 11:12:26.000000000 -0400
@@ -425,6 +425,10 @@ config TCP_CONG_BIC
 	increase provides TCP friendliness.
 	See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/
 
+	This is the default TCP congestion control and the kernel will
+	attempt to load it if possible.  If it is unable to initialize
+	tcp_bic, the TCP Reno algorithms will be used as a fallback.
+
 config TCP_CONG_WESTWOOD
 	tristate "TCP Westwood+"
 	select IP_TCPDIAG

(although that *still* doesn't document what's really going on with
the tcp_init_congestion_control() function, and how that sysctl value
interacts with things....




[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]