svn commit: r257455 - head/sys/net

[Andre Oppermann]

On 31.10.2013 20:27, Ian Lepore wrote:
> 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.

That's a totally different issue.  Here we're talking about kernel
structures including the fields in struct mbuf.  It is totally not
related to any payload packet headers inside the mbuf data section.

The problem you're complaining about is the epic design mistake of
the ethernet header neither being a power of two nor divisible by
4 or 8 bytes.  It is a ridiculous 14 bytes.

Many DMA engines are capable of starting on any byte.  Some (popular)
are not.  If they are, the start of the payload can be by shifted by
two so that the IP headers are 32bit aligned in memory.  If that is
not possible either the payload has to be copy-aligned or direct
payload to structure casting must be disallowed, or indirected through
a macro.

-- 
Andre