h_ertt cc_vegas loader.conf interaction on stable/8

[Jason Hellenthal]

Hi Larence,

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"?

Only 'newreno'

> 
> > 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.

Thank you.

> 
> Cheers,
> Lawrence