From owner-freebsd-net@FreeBSD.ORG Fri Oct 12 21:21:53 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FEB8953; Fri, 12 Oct 2012 21:21:53 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id B22CB8FC1A; Fri, 12 Oct 2012 21:21:52 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q9CLLplQ003892; Sat, 13 Oct 2012 01:21:51 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q9CLLp3H003891; Sat, 13 Oct 2012 01:21:51 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 13 Oct 2012 01:21:51 +0400 From: Gleb Smirnoff To: Adrian Chadd Subject: Re: [CFT/Review] net byte order for AF_INET Message-ID: <20121012212151.GB89655@glebius.int.ru> References: <20121009154128.GU34622@FreeBSD.org> <20121012124640.GW89655@FreeBSD.org> <20121012124709.GX89655@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 21:21:53 -0000 On Fri, Oct 12, 2012 at 05:06:29PM -0400, Adrian Chadd wrote: A> On 12 October 2012 08:47, Gleb Smirnoff 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.