From owner-svn-src-head@FreeBSD.ORG Tue Jun 3 17:06:02 2014 Return-Path: Delivered-To: svn-src-head@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 2E7ED120; Tue, 3 Jun 2014 17:06:02 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CBED82072; Tue, 3 Jun 2014 17:06:01 +0000 (UTC) Received: from [192.168.0.96] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.7) with ESMTP id s53H5tNk070916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jun 2014 17:05:58 GMT (envelope-from theraven@theravensnest.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: svn commit: r266974 - in head/sys: dev/dc dev/fxp dev/mii dev/netmap kern net From: David Chisnall In-Reply-To: Date: Tue, 3 Jun 2014 18:05:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201406021754.s52Hsd1B039620@svn.freebsd.org> <20140603012939.GA2998@michelle.cdnetworks.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1874) Cc: Yong-Hyeon Pyun , Marcel Moolenaar , "svn-src-all@freebsd.org" , Marcel Moolenaar , "src-committers@freebsd.org" , "svn-src-head@freebsd.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 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: Tue, 03 Jun 2014 17:06:02 -0000 On 3 Jun 2014, at 06:01, Adrian Chadd wrote: > I wonder if in the short term we should just use inlines for now, at > least so the methodization can get done without hurting people on > ARM/MIPS. It's probably worth thinking a bit more carefully about the KPI, since = it's something we'll likely be stuck with for a long time... If access to a particular field is on the hot path, and you're never = going to want to do interposition, then the obvious thing to do is have = a method that returns a pointer to the field so that you can cache it in = the caller. Some thought needs to be given there as to whether these = things are _Atomic() qualified for when we (eventually) move to C11 for = the kernel. For drivers that are compiled into the kernel, there's no issue with = making the call inline, but if we want to have a stable KBI for modules = then that needs to be conditional. I'm a bit wary about things that = will introduce significant performance differences between things built = as modules and compiled into the kernel. Longer term, there's also the possibility of shipping modules as LLVM IR = and doing install-time specialisation of them against the current = kernel, which would make avoiding the function call a premature = optimisation that we'd have to keep living with. David