From owner-svn-src-all@FreeBSD.ORG Thu Oct 31 20:15:18 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 38446BC0; Thu, 31 Oct 2013 20:15:18 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0AD9B2EF9; Thu, 31 Oct 2013 20:15:17 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vbye7-000Dae-FP; Thu, 31 Oct 2013 20:15:11 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r9VKF8nB056001; Thu, 31 Oct 2013 14:15:08 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/81FNDHYA5VaNUVeHPedmI Subject: Re: svn commit: r257455 - head/sys/net From: Ian Lepore To: Luigi Rizzo In-Reply-To: <20131031200502.GB83212@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> Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Oct 2013 14:15:08 -0600 Message-ID: <1383250508.31172.38.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Andre Oppermann 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 20:15:18 -0000 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. 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. -- Ian