From owner-svn-src-all@FreeBSD.ORG Wed May 7 16:07:00 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0643FCE; Wed, 7 May 2014 16:06:59 +0000 (UTC) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D74A4B6E; Wed, 7 May 2014 16:06:58 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id e53so898256eek.36 for ; Wed, 07 May 2014 09:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pPEYMBo0fmwSyo6ZjM6Ffys4wiN8wHn2WGBl4QEL90w=; b=UDlxBkoMjpEMn5cHRGtUqVH73zlknheKS05MbPlNbreF7dO/HzBV0eYajZRTMa7cPI IoqUVIz68sjRv0lvSjHpig5w2sbG6jNVQQvlEDtHXxrDOYpodB6RUXv2+VZOEapt2afa 3XGQemMrDzRyFIRJcRzMpZBaMueMN5LLuzqkSLSofuKR+RFq7k6KQxXVV4e64tI5DBRh sUYTqA8+0b3sWDpQO9+P4hwLf2cwt3Sq3nBAesExKtGSldoAfzUSBroQaJv9TdoxZVuL dJSBjb30U4IiRPbiWl481rfbP7q1cTqm5o8kJmRW0dBMDLeMpjsQfKP5sIUpj47OUMBh R92A== X-Received: by 10.14.213.6 with SMTP id z6mr16636557eeo.98.1399478816896; Wed, 07 May 2014 09:06:56 -0700 (PDT) Received: from strashydlo.home (aeaw217.neoplus.adsl.tpnet.pl. [79.186.22.217]) by mx.google.com with ESMTPSA id z48sm47263826eel.27.2014.05.07.09.06.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 09:06:56 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: svn commit: r265498 - stable/10/sys/dev/iscsi Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: Date: Wed, 7 May 2014 18:06:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201405070638.s476cK2J092699@svn.freebsd.org> To: Robert Watson X-Mailer: Apple Mail (2.1283) Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-10@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 16:07:00 -0000 Wiadomo=B6=E6 napisana przez Robert Watson w dniu 7 maj 2014, o godz. = 13:49: > On Wed, 7 May 2014, Edward Tomasz Napierala wrote: >=20 >> Author: trasz >> Date: Wed May 7 06:38:19 2014 >> New Revision: 265498 >> URL: http://svnweb.freebsd.org/changeset/base/265498 >>=20 >> Log: >> MFC r264025: >>=20 >> Get rid of the "autoscaling", instead just set socket buffer sizes >> in the usual way. The only thing the old code did was making things >> less predictable. >=20 > Does this mean that the autoscaling algorithm needs refining? The = problem with disabling autoscaling is that the code may, in the future, = fail to benefit from further global refinements, as old code that = hard-coded sizes now fails to do -- and that if we don't refine the = autoscaling model, other applications may fail to benefit. The commit message here was misleading - what got replaced was setting the socket buffer size "by hand" to a value computed from negotiated maximum PDU size. Now it's set to constant size. The reason we do not use autoscaling here is not performance. It's because iSCSI code can't transmit a part of PDU; it always waits until there is room for the whole thing (PDUs can be up to about 128kB in size). If the socket buffer size somehow got autoscaled below that amount, the transmit would stop indefinitely. There is a somewhat similar situation on the receive side. So, the right solution would be to either use autoscaling, but with a guarantee that the socket buffer won't shrink below some specified value, or have a way to determine that the socket buffer won't get any bigger anytime soon and so the iSCSI should transmit or receive a part of PDU. Current setting "by hand" is just a workaround, albeit pretty well working one.