Date: Tue, 27 Aug 2013 08:53:23 +0200 From: Andre Oppermann <andre@freebsd.org> To: Michael Tuexen <tuexen@freebsd.org> Cc: freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: ARM network trouble after recent mbuf changes Message-ID: <521C4CE3.9080400@freebsd.org> In-Reply-To: <3F762A16-3760-4FAA-B547-27529032AFEA@freebsd.org> 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> <3F762A16-3760-4FAA-B547-27529032AFEA@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27.08.2013 08:30, Michael Tuexen wrote: > On Aug 27, 2013, at 7:53 AM, Hans Petter Selasky <hps@bitfrost.no> 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. >> >> >> Hi, >> >> 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. > Isn't there a performance penalty when accessing 64-bit entities not being 64-bit > aligned? If that is the case, wouldn't it make sense to add a 4 byte padding to > struct m_hdr for ILP32? Then the problem should go away... Either that or define MLEN and MHLEN in a way that actually reflects the true size of what they are representing. The latter is the true bug. > We could also get rid of the 64 bit alignment by not having 64-bit entities in > struct pkthdr. Removing sixtyfour should be easy. However, we now have also > uint64_t csum_flags. Yes, the 64 bit fields are to be used to store packet associated information on its way through the stack. Reducing it to 32 bits would somewhat defeat their purpose. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?521C4CE3.9080400>