From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 11:13:13 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E44EF1065670; Fri, 12 Nov 2010 11:13:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5ED698FC0A; Fri, 12 Nov 2010 11:13:12 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oACAf9F3040496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Nov 2010 12:41:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oACAf9DK059842; Fri, 12 Nov 2010 12:41:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oACAf9K8059841; Fri, 12 Nov 2010 12:41:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Nov 2010 12:41:09 +0200 From: Kostik Belousov To: Lawrence Stewart Message-ID: <20101112104109.GY2392@deviant.kiev.zoral.com.ua> References: <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> <20100913172453.GG99657@mdounin.ru> <20100927081217.GM44164@mdounin.ru> <4CA09987.8020205@freebsd.org> <20101102001134.GP44164@mdounin.ru> <4CD090EF.4020402@freebsd.org> <4CD64814.2000906@freebsd.org> <4CDD0C7D.1070102@freebsd.org> <4CDD1529.8070504@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="N+om2BM+ElqV+U6I" Content-Disposition: inline In-Reply-To: <4CDD1529.8070504@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-net@freebsd.org, Igor Sysoev , Andre Oppermann , Maxim Dounin Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 11:13:14 -0000 --N+om2BM+ElqV+U6I Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 12, 2010 at 09:21:29PM +1100, Lawrence Stewart wrote: > On 11/12/10 20:44, Lawrence Stewart wrote: > > On 11/07/10 17:32, Lawrence Stewart wrote: > >> On 11/03/10 09:30, Andre Oppermann wrote: > >>> On 02.11.2010 01:11, Maxim Dounin wrote: > >>>> Hello! > >>>> > >>>> On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote: > >>>> > >>>>> On 27.09.2010 10:12, Maxim Dounin wrote: > >>>>>> Hello! > >>>>>> > >>>>>> On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote: > >>>>>> > >>>>>> [...] > >>>>>> > >>>>>>> Andre, could you please take a look at one more patch as well? > >>>>>>> > >>>>>>> Igor reported that it still sees 100ms delays with rfc3465 turned > >>>>>>> on, and it turns out to be similar issue (setting cwnd to 1*MSS) > >>>>>>> for hosts found in hostcache. > >>>>>>> > >>>>>>> The problem with setting cwnd from hostcache was already reported > >>>>>>> here: > >>>>>>> > >>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/92690 > >>>>>>> http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014780.h= tml > >>>>>>> > >>>>>>> As using larger cwnd from hostcache may cause problems on > >>>>>>> congested links (see second thread) I changed code to only use > >>>>>>> cached cwnd as an upper bound for cwnd (instead of fixing current > >>>>>>> code). This is also in-line with what we do on connection > >>>>>>> restarts. > >>>>>>> > >>>>>>> We may later consider re-adding usage of larger cwnd from > >>>>>>> hostcache. But I believe it should be done carefully and > >>>>>>> probably behind sysctl, off by default. > >>>>>> > >>>>>> Ping. > >>>>> > >>>>> Thanks for the reminder. I'll disable priming CWND from hostcache. > >>>> > >>>> Ping again. > >>>> > >>>> I would like to see the patch in question[1] committed and MFC'ed > >>>> somewhere before 8.2. > >>>> > >>>> Andre, if you are just too busy to do it yourself - please say so, > >>>> I'll ask somebody else to commit it. > >>> > >>> Thanks for the reminder. After EuroBSDCon Developer Summit I was > >>> busy with other work and most of my tcp work was stalled due to > >>> review bandwidth issues. > >> > >> Sorry for the review bandwidth issues. I'm only just managing to keep = my > >> head above water at the moment and have had to reduce much of my FreeB= SD > >> work to a trickle. > >> > >>> Lawrence, could you please spare a few seconds and take a quick look > >>> at the attached patch? > >> > >> The patch looks fine, please commit. I hope to give the hostcache some > >> TLC at some point, but in the meantime it's fine to ignore cached cwnd. > >=20 > > FYI Andre, this patch got rolled into r215166 because I had to move all > > the code around which the patch was based on. Is that going to cause any > > issues here? I should have checked prior to committing but completely > > forgot I had pulled the patch into my dev tree before creating the mod > > CC patch. >=20 > Gah, I think I've answered my own question. MFCing the patch standalone > in time for 8.2 as Maxim requested is not going to be possible. I think > I'll have to back out r215166, commit your patch and then recommit the > modular CC patch. >=20 > Unless someone can think of a way that doesn't involve all the mucking > about? Well, if the change is indeed already in HEAD, you can do a direct commit to stable/8 after proper MFC period, noting that this is a cherry-pick of the part of corresponding revision. --N+om2BM+ElqV+U6I Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzdGcQACgkQC3+MBN1Mb4gmywCeNialKmZswaQvBadXdyHZqhhE eLAAnA7jMUKYywgFzB0K1VKonZYH5B7S =EMru -----END PGP SIGNATURE----- --N+om2BM+ElqV+U6I--