From owner-svn-src-head@FreeBSD.ORG Thu Jan 22 11:19:02 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAB7DEBF; Thu, 22 Jan 2015 11:19:02 +0000 (UTC) Received: from lakerest.net (lakerest.net [162.235.35.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lakerest.net", Issuer "Stewart" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 778AD1F2; Thu, 22 Jan 2015 11:19:02 +0000 (UTC) Received: from [192.168.1.134] (173.64-138-239-net.sccoast.net [64.138.239.173]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id t0MBHvF0093229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jan 2015 06:17:57 -0500 (EST) (envelope-from rrs@lakerest.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.1\)) Subject: Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys From: Randall Stewart In-Reply-To: Date: Thu, 22 Jan 2015 06:18:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150120075126.GA42409@kib.kiev.ua> <20150120211137.GY15484@FreeBSD.org> <54BED6FB.8060401@selasky.org> <54BEE62D.2060703@ignoranthack.me> <54BEE8E6.3080009@ignoranthack.me> <54BEEA7F.1070301@ignoranthack.me> <54BEF154.3030606@ignoranthack.me> <20150121181512.GE15484@FreeBSD.org> To: Adrian Chadd X-Mailer: Apple Mail (2.2070.1) X-Mailman-Approved-At: Thu, 22 Jan 2015 12:51:01 +0000 Cc: Hans Petter Selasky , "src-committers@freebsd.org" , Kip Macy , Jason Wolfe , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" , Sean Bruno , Gleb Smirnoff , Konstantin Belousov , "M. Warner Losh" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 11:19:03 -0000 Let me re-send my email.. my silly mac sent my first try from the wrong = address.. sigh (sorry moderator where ever you are ;-o) All: I have finally pulled my head out of the sands of TLS and=20 had some time to look at this interesting long thread. I agree with Warner and Adrian on this.. Lets back it out and then in a branch chew this over piece by piece.. R As an addition I have decided to get my head back into this, I was one of the ones on Hann=E2=80=99s original email and I had asked him to wait until *after* the Holiday=E2=80=99s to do anything (thinking on continuing the discussion) I did *not* realize he planned on roto-tilling the callout system.. sigh =20 > On Jan 21, 2015, at 7:10 PM, Adrian Chadd wrote: >=20 > On 21 January 2015 at 16:07, K. Macy wrote: >>>> HPS: Your change failed to meet these guidelines. Some of us are = upset >>>> because these guidelines are fairly fundamental for the on-going >>>> viability of FreeBSD. Due to linguistic / time zone / cultural >>>> differences these expectations have not been adequately = communicated >>>> to you. You are not in the USB sandbox where others need for your >>>> support outweighs the inconvenience of random breakage. >>>>=20 >>>> It sounds like you are making progress towards updating the = concerns >>>> that have been voiced. If kib's observations are in fact = comprehensive >>>> then adding a callout_init_cpu function and updating all clients so >>>> that their callouts continue to be scheduled on a CPU other than = the >>>> BSP will suffice and we can all move on. >>>=20 >>> Is there some reason that we can=E2=80=99t back things out, break = things down into >>> smaller pieces and have everything pass through phabric with a wide >>> ranging review? Given the fundamental nature of these changes, they >>> really need better review and doing it after the fact seems to be to = be >>> too risky. I=E2=80=99m not debating that this =E2=80=9Cfixes=E2=80=9D = some issues, but given the >>> performance regression, it sure seems like we may need a different >>> solution to be implemented and hashing that out in a branch might be >>> the best approach. >>=20 >> Thank you. A more incremental approach would be appreciated by many = of >> us. To avoid the bystander effect we can permit explicit timeouts for >> review-to-commit (72 hours?) so that we don't collectively end up >> sandbagging him. >=20 > I'm +1 for this. >=20 >=20 >=20 > -a ------------------------------ Randall Stewart 803-317-4952 (cell)