From owner-svn-src-head@FreeBSD.ORG Thu Oct 31 22:29:31 2013 Return-Path: Delivered-To: svn-src-head@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 D6D33443 for ; Thu, 31 Oct 2013 22:29:31 +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 2C7C428B5 for ; Thu, 31 Oct 2013 22:29:31 +0000 (UTC) Received: (qmail 81738 invoked from network); 31 Oct 2013 22:59:37 -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 22:59:37 -0000 Message-ID: <5272D9B2.2060907@freebsd.org> Date: Thu, 31 Oct 2013 23:29:06 +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: Ian Lepore , 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> <1383250508.31172.38.camel@revolution.hippie.lan> In-Reply-To: <1383250508.31172.38.camel@revolution.hippie.lan> 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 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 22:29:31 -0000 On 31.10.2013 21:15, Ian Lepore wrote: > On Thu, 2013-10-31 at 21:05 +0100, Luigi Rizzo wrote: >> 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) >> >> cheers >> luigi > > Or if not that (I have no idea how frequently those fields are accessed > and what the performance penalty would be on systems moving a LOT of > packets), then a compromise might be a flag the driver can set to say it > may provide unaligned incoming packets. Then we could have common code > at just one place in the network stack to split the mbuf and > realign-copy just the protocol header part to a new mbuf and attach it > to the front of the chain. That would minimize both duplicated code and > the amount of data that has to be copied, and would put knowledge like > "how big is the protocol header that needs copying?" in a place that > knows more about protocols. This is a sensible idea and in fact how some of the drivers already do it internally for strict alignment architectures. > I know pretty much nothing about what happens in the network stack after > I feed a packet to if_input(), so maybe this is all impractical. But I > also know that ARM systems with strict alignment constraints spend a lot > of time copying the entire contents of every incoming packet to realign > it, and it would be a lot better if they were able to DMA directly into > an mbuf cluster that can handed up the stack. Even if "copy the entire > packet" is the only thing if_input() could do, there might still be some > benefit in having one common piece of code for it. We have tons of protocols using direct structure casting into the mbuf payload. Changing them all would be a huge task and in many cases also change the way the code is structured. -- Andre