Date: Sun, 1 Mar 2009 13:33:49 +0000 (GMT) From: Robert Watson <rwatson@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: r189230 - head/sys/net Message-ID: <alpine.BSF.2.00.0903011331090.51661@fledge.watson.org> In-Reply-To: <20090301132350.GB54337@onelab2.iet.unipi.it> References: <200903011242.n21CgsV1043573@svn.freebsd.org> <20090301132350.GB54337@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 1 Mar 2009, Luigi Rizzo wrote: > 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.: Jeff has a large work-in-progress on mbufs, and so I don't want to go near that until all that work has shaken out. This includes support for variable-size mbufs and eliminating large amounts of cluster use (while retaining support for external storage, a we require that for zero-copy foo). If you haven't seen his posts about that work, you might want to give them a skim -- I think they were on arch@/net@. I thought bio was less sensitive to change since it was centrally allocated these days, or is that not the case? ifnet is decreasingly sensitive. Robert N M Watson Computer Laboratory University of Cambridge > - 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?alpine.BSF.2.00.0903011331090.51661>