Date: Sun, 1 Mar 2009 14:23:50 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Robert Watson <rwatson@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r189230 - head/sys/net Message-ID: <20090301132350.GB54337@onelab2.iet.unipi.it> In-Reply-To: <200903011242.n21CgsV1043573@svn.freebsd.org> References: <200903011242.n21CgsV1043573@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 01, 2009 at 12:42:54PM +0000, Robert Watson wrote: > Author: rwatson > Date: Sun Mar 1 12:42:54 2009 > New Revision: 189230 > URL: http://svn.freebsd.org/changeset/base/189230 > > Log: > Do a bit of struct ifnet cleanup in preparation for 8.0: group function > pointers together, move padding to the bottom of the structure, and add > two new integer spares due to attrition over time. Remove unused spare > "flags" field, we can use one of the spare ints if we need it later. > > This change requires a rebuild of device driver modules that depend on > the layout of ifnet for binary compatibility reasons. any chance to do similar things for other key kernel structures, such as mbufs and struct bio ? As an example, "struct bio" would benefit from at least one extra intptr_t field to be used for classification purposes (see some recent work we have been doing on disk scheduling). This is a rather trivial and unintrusive change. struct mbuf would benefit from a 'length' field, replacing the hardcoded MLEN/MHLEN. This field would allow us to do several things, e.g.: - use part of the data area to store m_tags instead of having to malloc() them separately; - support multiple (or perhaps even runtime-configurable) mbuf sizes (and corresponding uma zones), so people could experiment with larger MBUFS and perhaps figure out what is the performance impact of using mbuf+clusters instead of individual mbufs for basically every incoming packet. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090301132350.GB54337>