From owner-svn-src-all@FreeBSD.ORG Thu Oct 31 22:36:01 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 4A041833 for ; Thu, 31 Oct 2013 22:36:01 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 91B342920 for ; Thu, 31 Oct 2013 22:36:00 +0000 (UTC) Received: (qmail 81786 invoked from network); 31 Oct 2013 23:06:07 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 Oct 2013 23:06:07 -0000 Message-ID: <5272DB37.6010801@freebsd.org> Date: Thu, 31 Oct 2013 23:35:35 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: John-Mark Gurney , Luigi Rizzo Subject: Re: svn commit: r257455 - head/sys/net 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> <20131031211337.GA83561@onelab2.iet.unipi.it> <20131031221457.GG58155@funkthat.com> In-Reply-To: <20131031221457.GG58155@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, 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 22:36:01 -0000 On 31.10.2013 23:14, John-Mark Gurney wrote: > Luigi Rizzo wrote this message on Thu, Oct 31, 2013 at 22:13 +0100: >> 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. > > I am/was trying to prevent massive code curn... > >> The copy to a stack buffer is probably useful even for readability > > Oh, I also realized I left out another part of it... > > void > ip_input(struct mbuf *m) > { > #ifndef __NO_STRICT_ALIGNMENT > struct ip tmpip; > #endif > struct ip *ip = NULL; > > #ifndef __NO_STRICT_ALIGNMENT > bcopy(mtod(m, struct ip *), &tmpip, sizeof tmpip); > ip = &tmpip; > #else > ip = mtod(m, struct ip *); > #endif Still massive code churn for all protocols above layer 3. > } >> 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 ?) > > If you modify the packet, you need to be careful to write back the > data when needed, i.e. passing the mbuf to another layer or > returning.. But that isn't anything too different than other > functions... Since the beginning and continuing the direct structure casting has been the way to access protocol data. Completely changing this would be a very big change requiring a throughout audit of the kernel. > Looks like I'll have to revive my TS-7200 port for testing as npe on > AVILA apparently can handle the slightly odd alignment... Architectures that have trouble with unaligned access should only be used with RX DMA engines that can 16bit align their writes. ;) Then it's only a call to m_adj before the mbuf is mapped into the RX ring and you're good. -- Andre