Date: Thu, 31 Oct 2013 23:29:06 +0100 From: Andre Oppermann <andre@freebsd.org> To: Ian Lepore <ian@FreeBSD.org>, Luigi Rizzo <rizzo@iet.unipi.it> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r257455 - head/sys/net Message-ID: <5272D9B2.2060907@freebsd.org> In-Reply-To: <1383250508.31172.38.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5272D9B2.2060907>