Re: tcp congestion policy selection link order fragile
On Sun, 17 Sep 2006 16:51:50 +0200 bert hubert <[EMAIL PROTECTED]> wrote: > The original message Stephen reacts to below apparently never made it to the > list, it can be found here: http://ds9a.nl/tmp/module-policy.txt > > > Any body who builds in random stuff without thinking is being foolish. > > But, if you can think of a better configuration method that isn't too > > grotty, then go for it. > > The method I'm proposing is simple enough: > > 1) reno is always built-in > 2) it is the default tcp congestion policy No, Reno is unstable in high BDP > 3) loading/compiling-in additional tcp congestion policies only make them >available > 4) userspace is free to select a non-default tcp congestion policy at will > > The implementation might be as simple as making the *first* registered > congestion policy the default (instead of the last one) which would be reno, > as it is in tcp_cong.o, which is probably always loaded first (as the other > .o's need symbols that are in tcp_cong.o). > > Despite what you allege about my foolishness, I maintain that a kernel that > enables a *random policy* from the ones you compiled in, is not a sane > kernel. > > The default kernel should be as sane as possible, allowing the userspace > people (ie, me) to mess things up to their heart's desire. > > Bert > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcp congestion policy selection link order fragile
On Mon, Sep 18, 2006 at 11:53:09AM -0700, David Miller wrote: > > What would the desired default be, 'BIC' in all cases? > > And if BIC is not enabled in the configuration, then what? As the source notes "/* we'll always have reno */ ". This would make the policy: the default is "bic" if available, otherwise it is "reno", which is *always* available. But it is all up to you. I'm willing to do the leg work. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcp congestion policy selection link order fragile
From: bert hubert <[EMAIL PROTECTED]> Date: Mon, 18 Sep 2006 17:40:48 +0200 > What would the desired default be, 'BIC' in all cases? And if BIC is not enabled in the configuration, then what? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcp congestion policy selection link order fragile
On Mon, Sep 18, 2006 at 07:06:00AM -0700, David Miller wrote: > Any ordering scheme is wrong or unexpected for _somebody_. Look how I agree violently. Would you agree that it would be best to have a mechanism that explicitly sets a sane default, and does not rely on ordering? My implementation indeed broke your intentions, but would you be open to revamping things so the default policy is not dependent on load order? What would the desired default be, 'BIC' in all cases? Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcp congestion policy selection link order fragile
From: bert hubert <[EMAIL PROTECTED]> Date: Mon, 18 Sep 2006 11:59:36 +0200 > I've tested this patch and it does the job for me, reno is now the default, > even when more advanced options are compiled in, but the rest is still > available. This breaks our intention that when TCP_CONG_ADVANCED is not set, BIC is the default since that is the default congestion control algorithm we want users to get. When TCP_CONG_ADVANCED is disabled, we turn on TCP_CONG_BIC, and your changes cause reno to be the default algorithm in that build case. That's not what we want. Any ordering scheme is wrong or unexpected for _somebody_. Look how easy it was for you to break the BIC default we had in place. To make things sensible for you, your patch causes everyone else got the wrong default. Therefore any ordering scheme is by definition arbitrary and no ordering is better than any other one. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcp congestion policy selection link order fragile
On Mon, Sep 18, 2006 at 01:51:30AM -0700, David Miller wrote:
> We created TCP_CONG_ADVANCED for a purpose. If you turn that
> thing on, you get full control but if something breaks you get
> to keep the pieces.
But we should not try to break stuff on purpose, no matter how advanced. It
makes zero sense. To reiterate, when compiling in multiple TCP policies, a
*random* one gets enabled. This is not something we want to offer even
advanced users. It is a kernel, not an adventure course.
Please consider this near-oneliner patch which makes stuff behave more like
people expect: loading a module, or compiling in a congestion avoidance
policy only makes it available, but does not turn it on by default.
It also cleans up two notices a bit.
I've tested this patch and it does the job for me, reno is now the default,
even when more advanced options are compiled in, but the rest is still
available.
When in doubt, consider that I discovered this because my kernel was
crashing, and that this is bound to generate heaps of annoying email
otherwise.
Thanks.
Signed-off-by: bert hubert <[EMAIL PROTECTED]>
--- linux-2.6.18-rc7/net/ipv4/tcp_cong.c.org2006-09-18 11:42:25.0
+0200
+++ linux-2.6.18-rc7/net/ipv4/tcp_cong.c2006-09-18 11:43:45.0
+0200
@@ -45,11 +45,11 @@
spin_lock(&tcp_cong_list_lock);
if (tcp_ca_find(ca->name)) {
- printk(KERN_NOTICE "TCP %s already registered\n", ca->name);
+ printk(KERN_NOTICE "TCP congestion control '%s' already
registered\n", ca->name);
ret = -EEXIST;
} else {
- list_add_rcu(&ca->list, &tcp_cong_list);
- printk(KERN_INFO "TCP %s registered\n", ca->name);
+ list_add_tail_rcu(&ca->list, &tcp_cong_list);
+ printk(KERN_INFO "TCP congestion control '%s' registered\n",
ca->name);
}
spin_unlock(&tcp_cong_list_lock);
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcp congestion policy selection link order fragile
From: bert hubert <[EMAIL PROTECTED]> Date: Sun, 17 Sep 2006 14:21:53 +0200 > Operators, distributors and even people who've been doing kernel stuff for > more than a decade expect to be able to compile in (experimental) policies, > and not have a *random* one of them enabled by default! We created TCP_CONG_ADVANCED for a purpose. If you turn that thing on, you get full control but if something breaks you get to keep the pieces. Quite frankly, just about everyone should not enable TCP_CONG_ADVANCED at all. And quite likely thie applies even distribution vendors. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcp congestion policy selection link order fragile
The original message Stephen reacts to below apparently never made it to the list, it can be found here: http://ds9a.nl/tmp/module-policy.txt > Any body who builds in random stuff without thinking is being foolish. > But, if you can think of a better configuration method that isn't too > grotty, then go for it. The method I'm proposing is simple enough: 1) reno is always built-in 2) it is the default tcp congestion policy 3) loading/compiling-in additional tcp congestion policies only make them available 4) userspace is free to select a non-default tcp congestion policy at will The implementation might be as simple as making the *first* registered congestion policy the default (instead of the last one) which would be reno, as it is in tcp_cong.o, which is probably always loaded first (as the other .o's need symbols that are in tcp_cong.o). Despite what you allege about my foolishness, I maintain that a kernel that enables a *random policy* from the ones you compiled in, is not a sane kernel. The default kernel should be as sane as possible, allowing the userspace people (ie, me) to mess things up to their heart's desire. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcp congestion policy selection link order fragile
On Sun, 17 Sep 2006 14:21:53 +0200 bert hubert <[EMAIL PROTECTED]> wrote: > On Sun, Sep 17, 2006 at 08:53:51PM +0900, Stephen Hemminger wrote: > > > Depending on load order is not good, and not a safe way to configure. > > I agree fully. > > > If you want a particular value set it with sysctl! > > Operators, distributors and even people who've been doing kernel stuff for > more than a decade expect to be able to compile in (experimental) policies, > and not have a *random* one of them enabled by default! Any body who builds in random stuff without thinking is being foolish. But, if you can think of a better configuration method that isn't too grotty, then go for it. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
