Date: Tue, 27 Aug 2013 07:22:30 -0600 From: Warner Losh <imp@bsdimp.com> To: Hans Petter Selasky <hps@bitfrost.no> Cc: Andre Oppermann <andre@freebsd.org>, freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: ARM network trouble after recent mbuf changes Message-ID: <16DC29EA-9D4D-4A57-8C16-913C344101C6@bsdimp.com> In-Reply-To: <521C3EE4.80801@bitfrost.no> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <FF0E227A-0E15-4AFB-9BA0-E0E903D953F9@freebsd.org> <521C3EE4.80801@bitfrost.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 26, 2013, at 11:53 PM, Hans Petter Selasky wrote: > On 08/27/13 00:38, Michael Tuexen wrote: >> I did some tests with a small program. Having in struct pkthdr 64 bit = entities >> results in a 64 bit alignment when used in struct mbuf. Using = __packed >> for struct mbuf, removes the padding. >=20 >=20 > Hi, >=20 > Maybe you could use __aligned(8) instead, and account for the extra = padding on all platforms? Packed has other disadvantages on ARM = platforms when accessing the structures, like that non-aligned access is = possible, and that it is sometimes slower than aligned access. Yes, __packed is generally a really bad idea for in-memory, performance = critical structures. In this case, __aligned(8) I don't think would have = much of an effect since the problem is a mismatch between MLEN and its = actual length (shame on whoever didn't put a compile time assert in = there).... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16DC29EA-9D4D-4A57-8C16-913C344101C6>