svn commit: r257455 - head/sys/net

[Ian Lepore]

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