[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <da8dbb76f0cb3762227d8d0a99eaff21@localhost>
Date: Tue, 31 May 2011 17:25:22 +0200
From: Hagen Paul Pfeifer <hagen@...u.net>
To: tsuna <tsunanet@...il.com>
Cc: "H.K. Jerry Chu" <hkjerry.chu@...il.com>,
David Miller <davem@...emloft.net>, <kuznet@....inr.ac.ru>,
<pekkas@...core.fi>, <jmorris@...ei.org>,
<yoshfuji@...ux-ipv6.org>, <kaber@...sh.net>,
<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tcp: Expose the initial RTO via a new sysctl.
On Tue, 31 May 2011 07:48:09 -0700, tsuna <tsunanet@...il.com> wrote:
> I talked to Jerry and he's agreed to share some patches that Google
> has been using internally for years.
Great!
> Personally what I think would be ideal would be:
> 1. A sysctl knob for initRTO, to allow people to adjust this
> appropriately for their environment.
> 2. Apply the srtt / rttvar seen on previous connections to new
> connections.
>
> Does that sound reasonable?
>
> For 2), I'm not sure how the details would work yet, I believe the
> kernel already has what's necessary to remember these things on a per
> peer basis, but it would be nice if I could specify things like "for
> 10.x.0.0/16 (local datacenter) use this aggressive setting, for
> 10.0.0.0/8 (my internal backend network) use that, for everything else
> (Internets etc.) use the default".
Skip sysctl, it is deprecated. The initRTO is the ideal candidate for a
per route knob. And happily you will solve 2) with the per route thing too!
;-)
Search the web, you will find some patches where you can see how to extend
the per route system - including iproute2.
Hagen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists