From owner-svn-src-all@FreeBSD.ORG Thu Oct 31 19:27:35 2013 Return-Path: Delivered-To: svn-src-all@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 ESMTP id 35CA5BF7; Thu, 31 Oct 2013 19:27:35 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BCE382B20; Thu, 31 Oct 2013 19:27:34 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vbxtw-0006Mx-Du; Thu, 31 Oct 2013 19:27:28 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r9VJRPpt055963; Thu, 31 Oct 2013 13:27:25 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX191gGP2cWm/TwcHs47pwYOk Subject: Re: svn commit: r257455 - head/sys/net From: Ian Lepore To: Andre Oppermann In-Reply-To: <5272AAC4.4030700@freebsd.org> References: <201310311546.r9VFkAIb049844@svn.freebsd.org> <20131031180336.GA62132@onelab2.iet.unipi.it> <5272AAC4.4030700@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Oct 2013 13:27:25 -0600 Message-ID: <1383247645.31172.29.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Luigi Rizzo X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 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: Thu, 31 Oct 2013 19:27:35 -0000 On Thu, 2013-10-31 at 20:08 +0100, Andre Oppermann wrote: > On 31.10.2013 19:03, Luigi Rizzo wrote: > > On Thu, Oct 31, 2013 at 03:46:10PM +0000, Andre Oppermann wrote: > >> Author: andre > >> Date: Thu Oct 31 15:46:10 2013 > >> New Revision: 257455 > >> URL: http://svnweb.freebsd.org/changeset/base/257455 > >> > >> Log: > >> Make struct ifnet readable and comprehensible again by grouping > >> and ordering related variables, fields and locks next to each > >> other. Add more comments to variables. > > > > > >> Over time 'ifnet' has accumlated a lot of additional pointers and > >> functionality in an unstructured way making it quite hard to read > >> and understand while obfuscating relationships between fields and > >> variables. > >> > >> Quantify the structure size and how bloated it has become. > >> > >> This is only a mechanical change in preparation for upcoming > >> work to make ifnet opaque to drivers and to separate out the > >> interface queuing. > > > > as you do the above I think it would make sense to replace > > all int/short/long with fixed-size fields as appropriate > > (and large enough) to make it easier to reason about things > > such as 'how many flags can i stuff into a field'. > > > > The "large enough" part refers to two things: > > - bitfields containing flags or capabilities have a tendency > > to overflow (not just in freebsd, linux has the same) > > requiring KBI changes. We should probably go for 64 bits > > unless there are compelling space reasons (not for ifnet). > > Gleb will handle most of that and it is going to be part of the making > ifnet opaque to drivers. > > > - it is useful if certain opaque fields (flow ids, cookies...) > > can store pointers. Once again, make them at least 64 bit helps > > A number of mbuf header fields have this property now. :) > Is there any chance all this reworking might get us to a position where the protocol header in an mbuf doesn't have to be 32-bit aligned anymore? We pay a pretty heavy price for that requirement in the drivers of the least capable hardware we support, the systems that have the least horsepower to spare to make an extra copy of each packet to realign it. -- Ian