h_ertt cc_vegas loader.conf interaction on stable/8
jhell at DataIX.net
Wed Sep 21 03:32:17 UTC 2011
On Wed, Sep 21, 2011 at 12:39:28PM +1000, Lawrence Stewart wrote:
> 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.
Yes that is what I was thinking but have not had the time to
specifically track it down.
> 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.
More information about the freebsd-stable