From owner-freebsd-net@FreeBSD.ORG Sat Oct 13 18:32:45 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 C348061A for ; Sat, 13 Oct 2012 18:32:45 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 45AFE8FC16 for ; Sat, 13 Oct 2012 18:32:43 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c50so2508359eek.13 for ; Sat, 13 Oct 2012 11:32:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:from:date:to:cc:message-id :x-gm-message-state; bh=niKOUxI76l/hY8ymPFZFB7QOrT2BJDHaNaIdPvakWSo=; b=Ghy+E9fpj7pmz7pHDIDejnIPimMDtzuI0FMGVXyYD+jqi3A2mYpo6DPvK1tAxutU53 YZUdX1NsRFubu+mvba2JmfuSnkhOAxOnX3q/QtLh7DLjF8lQ+/3Eb6ZCfWjdl7ITOddA 0bSYpDNQ/L+jZl2Asjt2ORrfTu4UAcTlXYGydK5QwgAXK54oy5wfn/Y03dcacVX/x9tL krqsXNsyIlHIyfEi+WC/yju8ZpsUD0++GCpdWDJ8AT2eQ8a2MKlL2oiLJLS7qiw61OUU a2E8+ZkwZ8BnR8F6VFId3810a6Ae9nBNt009IzqTrWoJ3CFsRmf0EIl1p7LqFNCytT4o aFDg== Received: by 10.14.200.134 with SMTP id z6mr10579639een.33.1350153162901; Sat, 13 Oct 2012 11:32:42 -0700 (PDT) Received: from [88.154.85.155] ([88.154.85.155]) by mx.google.com with ESMTPS id v3sm17171676een.1.2012.10.13.11.32.39 (version=SSLv3 cipher=OTHER); Sat, 13 Oct 2012 11:32:41 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <20121012212151.GB89655@glebius.int.ru> References: <20121009154128.GU34622@FreeBSD.org> <20121012124640.GW89655@FreeBSD.org> <20121012124709.GX89655@FreeBSD.org> <20121012212151.GB89655@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [CFT/Review] net byte order for AF_INET From: Aleksandr Rybalko Date: Sat, 13 Oct 2012 21:32:28 +0300 To: Gleb Smirnoff ,Adrian Chadd Message-ID: <2b582820-0095-4dbe-b929-ba5eb9d4e0ee@email.android.com> X-Gm-Message-State: ALoCoQnzkuwpFEa6Xb0FIXDQWBNaXYl2il2pqa0fXc40p2qzZv+feX21AtVGzhEczy6XHPe/jP0C 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: Sat, 13 Oct 2012 18:32:45 -0000 Gleb Smirnoff написал(а): >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) 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