[CFT/Review] net byte order for AF_INET

[Gleb Smirnoff]

On Fri, Oct 12, 2012 at 05:06:29PM -0400, Adrian Chadd wrote:
A> On 12 October 2012 08:47, Gleb Smirnoff <glebius at freebsd.org> wrote:
A> > On Fri, Oct 12, 2012 at 04:46:40PM +0400, Gleb Smirnoff wrote:
A> > T>   Latest version of patch for further review and testing
A> > T> Changelog:
A> > T>  - Fixed TCP checksums
A> > T>  - Added comment about raw sockets byte ordering.
A> > T>  - More explicit htons(0), when assigning ip_off field.
A> 
A> I've just eyeballed the patch again:
A> 
A> * You've patched SCTP and IGMP - have you done any SCTP and IGMP testing at all?
A> * This kind of stuff almost begs for some kind of automated test suite
A> for testing IPv4, IPv6, TCP/UDP/ICMP, IGMP, SCTP, all the tunneling
A> stuff - is there anything out there like this? I know of the IPv6 test
A> suites that exist; what about being able to regression test the other
A> stuff?

Not tested yet:

SCTP
IGMP
IPSEC
siftr(4)
mrouting
pfsync, pf_route()
stf(4)
ng_ipfw(4)

Tested:

TCP/UDP/ICMP
ip_fragment/ip_reass
raw socket
gre(4) as if_gre and as ng_pptpgre
gif(4)
pf(4)
ipfw(4)
divert(4)

A> Also whilst I'm nitpicking - do you think there's any performance
A> issues that may creep up? Remember that "performance issues" to me
A> don't necessarily mean "on a current generation intel", but mean "all
A> those cache starved ARM/MIPS/PPC/Atom boards out there that aren't
A> natively in network byte order." Making everything use network byte
A> order throughout the stack is nice for read-only packet work and nice
A> for cache-happy i386s, but what about the rest of the world?

Well, there may be unmeasurable impact. Just a few instructions per
packet. Some functions may be optimized to store converted length in
local variable and perform one or two ntohs() operations less. But
better as a separate change. We've got much more fat optimization
targets in stack than this.

A> (Don't get me wrong, I think this tidy-up is very nice and maybe quite
A> needed, I just wonder what other unknown magic is hiding behind the
A> existing code..)

There is so much magic here, and I want to just wipe it away instead
of learning it to depths. The motivation to finally start this work and
get it done is several panics due to packet in wrong byte order, which I
am failing to parse and model out which codepath could lead to them. Thus
I decided to fix that in principle.

-- 
Totus tuus, Glebius.