From owner-svn-src-all@FreeBSD.ORG Mon Dec 1 15:55:59 2014 Return-Path: Delivered-To: svn-src-all@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 CACD974A; Mon, 1 Dec 2014 15:55:59 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id B4F4F29; Mon, 1 Dec 2014 15:55:59 +0000 (UTC) Received: from [100.93.87.91] (184.sub-70-197-13.myvzw.com [70.197.13.184]) by elvis.mu.org (Postfix) with ESMTPSA id 77A87341F867; Mon, 1 Dec 2014 07:55:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: svn commit: r275136 - in head/sys: dev/e1000 dev/ixgbe kern sys From: Alfred Perlstein X-Mailer: iPhone Mail (12B436) In-Reply-To: <1762770.yx1cv63jp7@ralph.baldwin.cx> Date: Mon, 1 Dec 2014 07:55:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6753416A-D6FD-47F4-A62E-99A6ABB9B4B2@mu.org> References: <201411262019.sAQKJaw4043557@svn.freebsd.org> <39377603.10OyiSzjWY@ralph.baldwin.cx> <872C180A-6ADD-469F-A801-3728DF134EEC@mu.org> <1762770.yx1cv63jp7@ralph.baldwin.cx> To: John Baldwin Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , Alfred Perlstein , "src-committers@freebsd.org" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 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: Mon, 01 Dec 2014 15:55:59 -0000 > On Dec 1, 2014, at 7:49 AM, John Baldwin wrote: >=20 >> On Monday, December 01, 2014 07:19:13 AM Alfred Perlstein wrote: >> John, >>=20 >> Will work on a new revision based on feedback. >>=20 >> Two things to note however: >>=20 >> Already explored the idea of using kernel_sysctlbyname but rejected due t= o >> following: >>=20 >> It makes little sense to have a rw sysctl that only takes effect "some >> times". This violates POLA at the expense of making code appear cleaner. >> Expectation is that writable sysctls take effect or are read only. They a= re >> not to be "write sometimes" unless we are to introduce a new flag. Instea= d >> of going to a confusing model we consider some form of rw sysctl that can= >> set itself ro somehow. Otherwise people will be confused as to why nic >> queues says N while actually M. What the rw->ro api would look like I ha= ve >> no idea. Suggestions? >=20 > This is only somewhat true. In the near distant future we will have a dev= ctl=20 > tool which would let you do 'devctl detach igb0 && devctl attach igb0' whi= ch=20 > would honor your post-boot setting of hw.igb.num_queues. Instead what is=20= > important to understand about this particular sysctl node is that it only=20= > takes affect when a device is attached. However, there are other control=20= > knobs that also only affect future operations and not existing instances o= f=20 > objects, so I don't think this is that big of a leap. >=20 Strongly disagree here. If I were not able to grok the c code I would be ve= ry confused by such a thing. In fact even with the fact that I do grok c cod= e I would be very discouraged to find such behavior and strongly object to w= ritable sysctls that do nothing.=20 The ux is that the user has a bunch of dials on their dashboard that functio= n as a busybox as opposed to doing what they are advertised to do. Sort of l= ike those crossing light buttons in New York City that aren't actually hooke= d to anything.=20 So: No. Frankly would rather back out the change entirely and keep this chan= ge local to us than expose users to such a UX.=20 I will however like to discuss the possibility of a tunable/sysctl system th= at makes sense.=20 -Alfred.=20 > --=20 > John Baldwin >=20