Hi Jason, On 09/20/11 14:27, Jason Hellenthal wrote:
On stable/8 as of the date of this message when attempting the following configuration the sysctl MIB net.inet.tcp.cc.algorithm is not available for /etc/sysctl.conf to tune for whatever reason. /boot/loader.conf: h_ertt_load="YES" cc_vegas_load="YES" /etc/sysctl.conf: net.inet.tcp.cc.algorithm=vegas After boot the system still has the congestion algo set to 'newreno'
Does "sysctl net.inet.tcp.cc.available" after boot show only 'newreno' in the list? Or is 'vegas' listed as well after 'newreno', even though 'newreno' is listed by "sysctl net.inet.tcp.cc.algorithm"?
To get around this I had to load the above two modules at rc.local stage of the boot and also tune the sysctl via this method. Has anyone else seen this behavior with other congestion algo's ? Can any developer advise what is controlling this ?
hmm this smells like a bug in the ordering of module registration vs framework init, as I certainly intended that the code work in the way you tried to set it up.
From sys/netinet/cc/cc_module.h, you can see that CC modules attach at SI_SUB_PROTO_IFATTACHDOMAIN stage with order SI_ORDER_ANY.
From sys/netinet/cc/cc.c, "SYSINIT(cc, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_FIRST, cc_init, NULL);", so the framework is supposed to initialise at the same kernel boot stage as algorithm modules, but before any modules do.
I don't see any obvious problems with the current code, but will try reproduce here and follow up with my results.
Cheers, Lawrence _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"