From owner-freebsd-net@FreeBSD.ORG Fri May 30 17:00:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70D3F1065676 for ; Fri, 30 May 2008 17:00:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 47A108FC18 for ; Fri, 30 May 2008 17:00:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 845741109B8; Fri, 30 May 2008 13:00:55 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 30 May 2008 13:00:55 -0400 X-Sasl-enc: 9RpeTtzVrQw3gtyzsoDjMjvVKjx+NPyVKKNsGGq5CbUw 1212166855 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id EFE7E2B46F; Fri, 30 May 2008 13:00:54 -0400 (EDT) Message-ID: <484032C5.3090601@FreeBSD.org> Date: Fri, 30 May 2008 18:00:53 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: rihad References: <483FFE36.7050006@mail.ru> <4840200F.6070602@FreeBSD.org> <484024A5.6080109@mail.ru> In-Reply-To: <484024A5.6080109@mail.ru> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: if_var.h micro-optimization X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2008 17:00:56 -0000 rihad wrote: > Bruce M. Simpson wrote: >> >> It could save dirtying an L2 data cache line at the expense of taking >> a conditional branch, > Whoa, why don't you take it easy on me :) I'm not that much into > kernel (or hardware) programming. It's just that reading Ch. 3 of > TCP/IP Illustrated Vol.2 by Rich Stevens got me digging around FreeBSD > source code dealing with struct ifnet, where this piece of code caught > my attention. It could be red, it could be yellow. It could be 620nm. Who am I to say what is and what isn't? ;-) There are bound to be situations where the change is a win, and even some where there isn't. Context is everything... >> but to evaluate your suggested change requires a lot more data. Do >> you plan to do this? > Perhaps there is already a framework for trying out changes in > -CURRENT and seeing their relative impact, so perhaps someone more > experienced than I am can see to this? All educators are busy right now, please hold and the next available dogma merchant will be with you as soon as possible. ;-) (Hint: No, there isn't a framework I know of, unless you wanna make one? Scientific process applies, reproducible results, etc. You could script stuff, figure out a way to run the kernel or parts of the network stack under Valgrind so it can be L2 profiled w/o running it on a real machine... or hack hwpmc so it can be done live.. anything is possible.) > >> Given how _IF_DEQUEUE() is normally used the impact is likely >> negligible. > Oh, I see. A nice first attempt of mine anyway ;) Thanks. Don't take my word for it, down that road lies darkness. Seriously though -- it's easy to introduce bugs doing things like this, if anything else it's an exercise in really thinking things through. cheers BMS