[CFT/Review] net byte order for AF_INET

[Adrian Chadd]

.. sounds like the beginning of a wiki page to me, describing the mini
project, the latest status and the latest patch.

:)


Adrian


On 13 October 2012 11:32, Aleksandr Rybalko <ray at ddteam.net> wrote:
> 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>
>
>