On 31.10.2013 23:32, Ian Lepore wrote:
On Thu, 2013-10-31 at 23:17 +0100, Andre Oppermann wrote:
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.
Of course it is. The nature of my message was purely "As long as we're
doing big changes...".
It's in a totally different area, but agreed on the big changes thing. ;)
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.
Indeed.
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.
I know of only one modern ARM SoC that's able to DMA network packets on
a 2-byte boundary (actually even it requires a 4-byte boundary, but it's
willing to stuff the first 16 bits with zeroes and offset everything
that follows accordingly). I'm sure there are others, but it's the
exception rather than the rule.
Talk about foot shooting. I'm afraid that packet copying may still be
the least evil option in the grand scheme of things. IIRC ARM64 will
be able to do misaligned accesses with only a small performance penalty,
like x86/AMD64.
--
Andre
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
