[CFT/Review] net byte order for AF_INET

[Aleksandr Rybalko]

Gleb Smirnoff <glebius at FreeBSD.org> написал(а):

>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)

No, ng_ipfw tested :-)

>
>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.


WBW
------
Aleksandr Rybalko <ray at ddteam.net>