h_ertt cc_vegas loader.conf interaction on stable/8

[K. Macy]

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