freebsd stable - Sep 2011 - h_ertt cc_vegas loader.conf interaction on stable/8

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'

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 ?


Thanks in advance.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20110920/719dbdc1/attachment.pgp

On Tue, Sep 20, 2011 at 6:27 AM, Jason Hellenthal <jhell@dataix.net>
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.

What (I think) you're in essence asking is for the kernel to
dynamically load cc algorithms when you set the sysctl for the default
to one that has not yet been loaded. Below is the sysctl handler,
you'll see that it only lets you set it to an algorithm that has
already been loaded. Yes it would be possible to dynamically load the
way system does with ifconfig, but I don't know how many people would
feel that it was the effort of adding the code to iterate through all
the modules in a path looking for one that provided the name that had
been set.


Cheers



/*
 * Sysctl handler to show and change the default CC algorithm.
 */
static int
cc_default_algo(SYSCTL_HANDLER_ARGS)
{
	char default_cc[TCP_CA_NAME_MAX];
	struct cc_algo *funcs;
	int err, found;

	err = found = 0;

	if (req->newptr == NULL) {
		/* Just print the current default. */
		CC_LIST_RLOCK();
		strlcpy(default_cc, CC_DEFAULT()->name, TCP_CA_NAME_MAX);
		CC_LIST_RUNLOCK();
		err = sysctl_handle_string(oidp, default_cc, 1, req);
	} else {
		/* Find algo with specified name and set it to default. */
		CC_LIST_RLOCK();
		STAILQ_FOREACH(funcs, &cc_list, entries) {
			if (strncmp((char *)req->newptr, funcs->name,
			    TCP_CA_NAME_MAX) == 0) {
				found = 1;
				V_default_cc_ptr = funcs;
			}
		}
		CC_LIST_RUNLOCK();

		if (!found)
			err = ESRCH;
	}

	return (err);
}


> /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'
>
> 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 ?
>
>
> Thanks in advance.
>

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