Date: Sat, 13 Oct 2012 21:32:28 +0300 From: Aleksandr Rybalko <ray@ddteam.net> To: Gleb Smirnoff <glebius@FreeBSD.org>,Adrian Chadd <adrian@FreeBSD.org> Cc: net@FreeBSD.org Subject: Re: [CFT/Review] net byte order for AF_INET Message-ID: <2b582820-0095-4dbe-b929-ba5eb9d4e0ee@email.android.com> In-Reply-To: <20121012212151.GB89655@glebius.int.ru> References: <20121009154128.GU34622@FreeBSD.org> <20121012124640.GW89655@FreeBSD.org> <20121012124709.GX89655@FreeBSD.org> <CAJ-VmomVRH6gAA5busSVAgCa0As7v=HF41XQSL_BUx=NXRj04w@mail.gmail.com> <20121012212151.GB89655@glebius.int.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Gleb Smirnoff <glebius@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@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@ddteam.net>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2b582820-0095-4dbe-b929-ba5eb9d4e0ee>