From owner-svn-src-all@FreeBSD.ORG Thu Oct 31 20:03:15 2013 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CAC7E300; Thu, 31 Oct 2013 20:03:15 +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 898932DEE; Thu, 31 Oct 2013 20:03:15 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 06CED7300A; Thu, 31 Oct 2013 21:05:03 +0100 (CET) Date: Thu, 31 Oct 2013 21:05:03 +0100 From: Luigi Rizzo To: Ian Lepore Subject: Re: svn commit: r257455 - head/sys/net Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1383247645.31172.29.camel@revolution.hippie.lan> 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 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:03:15 -0000 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