h_ertt cc_vegas loader.conf interaction on stable/8

Lawrence Stewart lstewart at freebsd.org
Wed Sep 21 02:58:29 UTC 2011


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


More information about the freebsd-stable mailing list