From owner-freebsd-net@FreeBSD.ORG Tue Feb 5 19:11:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 068222A6; Tue, 5 Feb 2013 19:11:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D65CE112; Tue, 5 Feb 2013 19:11:19 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 57B05B924; Tue, 5 Feb 2013 14:11:19 -0500 (EST) From: John Baldwin To: Randall Stewart Subject: Re: Driver patch to look at... Date: Tue, 5 Feb 2013 14:11:17 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201302051352.52741.jhb@freebsd.org> <990BD290-643B-4BC7-8D64-6D4CE987025A@lakerest.net> In-Reply-To: <990BD290-643B-4BC7-8D64-6D4CE987025A@lakerest.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201302051411.17883.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 05 Feb 2013 14:11:19 -0500 (EST) Cc: freebsd-net@freebsd.org, Robert Watson , Jack Vogel , Kip Macy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:11:20 -0000 On Tuesday, February 05, 2013 2:04:12 pm Randall Stewart wrote: > Hmm >=20 > That would trade off a stack pointer + a compare > vs always doing the move. Right, the store is probably cheaper than the branch. :) However, minimizi= ng=20 the duplicated code in drivers and having this interface be as clear/readab= le=20 as possible is my main goal. > Thats fine until I have to add the _mc() version, then the put > back would be an atomic, and most of the time the return from > this is probably not changed=85 >=20 > I really would prefer not to since the compare and maybe store vs > the always store.. though the same now, would be far more expensive > in the _mc version.. if we do a _mc version of course ;-) I would just not bother with an _mc version until we actually need it. :) I think doing the sort of peek/advance type logic only works well with single consumers anyway. =2D-=20 John Baldwin