From owner-freebsd-net@FreeBSD.ORG Sun Oct 14 13:49:49 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 7B2F53A8; Sun, 14 Oct 2012 13:49:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 417FC8FC14; Sun, 14 Oct 2012 13:49:49 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so4351322pad.13 for ; Sun, 14 Oct 2012 06:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Zq3rSCSY4EAKrnS4QSnj1pJyFlKnPSKdAJfdwX+pjis=; b=FuLz4ioUpk3zSV5mE3/DsZDRnZLFuc+JnoJbDRvG4z87EJqIYLZGz2FvOJohRG5DAC tCA01MNsEPf9dulbvZZnGLI3dum1MLEdoYKreFs6iXL3ZOUgNWrUAlXmVWUCL9ist+Cn W5Izl5xusH7VELw+H4cFoe+rYP4vq1DNNtq8konEtJokwI66xZZO5cn31MKRdzNPBRb1 IhGwveXjqHxdL9prZxM5IgzEXFjF/EndW4PutqI9zX5yRhNvCan9SiShRjuJd/wdurgS pFhztU4uolfH/vq+2M4DD/Bcq/k2Ovch0DAX/RlmcEZpig4CnCuT0smwuB70AyiNiCLC LR2w== MIME-Version: 1.0 Received: by 10.68.218.226 with SMTP id pj2mr29566933pbc.33.1350222589004; Sun, 14 Oct 2012 06:49:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Sun, 14 Oct 2012 06:49:48 -0700 (PDT) In-Reply-To: <2b582820-0095-4dbe-b929-ba5eb9d4e0ee@email.android.com> References: <20121009154128.GU34622@FreeBSD.org> <20121012124640.GW89655@FreeBSD.org> <20121012124709.GX89655@FreeBSD.org> <20121012212151.GB89655@glebius.int.ru> <2b582820-0095-4dbe-b929-ba5eb9d4e0ee@email.android.com> Date: Sun, 14 Oct 2012 06:49:48 -0700 X-Google-Sender-Auth: GZ6TXz2zLdDLiraPr0soyP0cCW8 Message-ID: Subject: Re: [CFT/Review] net byte order for AF_INET From: Adrian Chadd To: Aleksandr Rybalko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Sun, 14 Oct 2012 13:49:49 -0000 .. 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 wrote: > Gleb Smirnoff =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= =D0=BB(=D0=B0): > >>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 > >