Date: Thu, 31 Oct 2013 20:08:52 +0100 From: Andre Oppermann <andre@freebsd.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r257455 - head/sys/net Message-ID: <5272AAC4.4030700@freebsd.org> In-Reply-To: <20131031180336.GA62132@onelab2.iet.unipi.it> References: <201310311546.r9VFkAIb049844@svn.freebsd.org> <20131031180336.GA62132@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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. :) -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5272AAC4.4030700>