From owner-svn-src-all@FreeBSD.ORG Thu Oct 31 21:11:53 2013 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A0606E9D; Thu, 31 Oct 2013 21:11:53 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 55B9F23BA; Thu, 31 Oct 2013 21:11:50 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 80A3B7300A; Thu, 31 Oct 2013 22:13:37 +0100 (CET) Date: Thu, 31 Oct 2013 22:13:37 +0100 From: Luigi Rizzo To: John-Mark Gurney Subject: Re: svn commit: r257455 - head/sys/net Message-ID: <20131031211337.GA83561@onelab2.iet.unipi.it> References: <201310311546.r9VFkAIb049844@svn.freebsd.org> <20131031180336.GA62132@onelab2.iet.unipi.it> <5272AAC4.4030700@freebsd.org> <1383247645.31172.29.camel@revolution.hippie.lan> <20131031200502.GB83212@onelab2.iet.unipi.it> <20131031204916.GF58155@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131031204916.GF58155@funkthat.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Andre Oppermann , Ian Lepore X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 21:11:53 -0000 On Thu, Oct 31, 2013 at 01:49:16PM -0700, John-Mark Gurney wrote: > Luigi Rizzo wrote this message on Thu, Oct 31, 2013 at 21:05 +0100: > > On Thu, Oct 31, 2013 at 01:27:25PM -0600, Ian Lepore wrote: > > ... > > > Is there any chance all this reworking might get us to a position where > > > the protocol header in an mbuf doesn't have to be 32-bit aligned > > > anymore? We pay a pretty heavy price for that requirement in the > > > drivers of the least capable hardware we support, the systems that have > > > the least horsepower to spare to make an extra copy of each packet to > > > realign it. > > > > So are you suggesting to use some 'copy_unaligned_32()' function/macro to > > access 32-bit protocol fields in the network stack ? > > (16-bit entries should not be an issue) > > my idea has been to make a change to the various ip/tcp/udp layers > that is dependant upon __NO_STRICT_ALIGNMENT and if we do require > strict alignment to copy the header to a stack buffer to align the > data... I'd rather use accessors functions/macros to read/write the unaligned headers so we can hide the #ifdefs in only one place. The copy to a stack buffer is probably useful even for readability regardless of alignment (i do this in ipfw so i parse the packet only once, and those values are used often), but we should be careful to keep the copy in sync with the original in places where those headers are modified (NAT, ipfw fwd, maybe somewhere else ?) cheers luigi