From owner-freebsd-stable@FreeBSD.ORG Wed Sep 21 03:32:17 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 963471065678 for ; Wed, 21 Sep 2011 03:32:17 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8458FC0C for ; Wed, 21 Sep 2011 03:32:16 +0000 (UTC) Received: by gyf2 with SMTP id 2so1094388gyf.13 for ; Tue, 20 Sep 2011 20:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=IXmlFtpZvSRflMghwSgZ37eo0cLZXxfCepOPA1uOWLc=; b=eLYXmOrC94Lr1UybjBYF2mP/qtCMiK9b/WIKUH/e+qvACVRBXMZ8Y5PqJUWqqJKiaT eNn7iNmqqHT50REq15RiERbXV2XFJ4w0xwNVLmApqESwL7mLgdYDzJxmNNQfLIqnS8Ju Zbiqni083ayprRteG3pH7+DTZouQMK1YawPZc= Received: by 10.236.77.133 with SMTP id d5mr1420876yhe.75.1316575936329; Tue, 20 Sep 2011 20:32:16 -0700 (PDT) Received: from DataIX.net (adsl-99-190-81-85.dsl.klmzmi.sbcglobal.net. [99.190.81.85]) by mx.google.com with ESMTPS id h20sm17317324ann.7.2011.09.20.20.32.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 20:32:15 -0700 (PDT) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id p8L3WBlB059482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Sep 2011 23:32:12 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id p8L3WBUY059481; Tue, 20 Sep 2011 23:32:11 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 20 Sep 2011 23:32:11 -0400 From: Jason Hellenthal To: Lawrence Stewart Message-ID: <20110921033211.GA59313@DataIX.net> References: <20110920042748.GA2746@DataIX.net> <4E794E60.6000600@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E794E60.6000600@freebsd.org> Cc: stable@freebsd.org Subject: Re: h_ertt cc_vegas loader.conf interaction on stable/8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 03:32:17 -0000 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