From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 06:58:34 2013 Return-Path: Delivered-To: freebsd-arm@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 C5E70370; Tue, 27 Aug 2013 06:58:34 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 587442FE1; Tue, 27 Aug 2013 06:58:34 +0000 (UTC) Received: from [10.0.1.102] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C759E1C0C0692; Tue, 27 Aug 2013 08:58:32 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ARM network trouble after recent mbuf changes From: Michael Tuexen In-Reply-To: <521C4CE3.9080400@freebsd.org> Date: Tue, 27 Aug 2013 08:58:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <627451FE-4F20-4E4D-9B24-59E0F340EF75@freebsd.org> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C3EE4.80801@bitfrost.no> <3F762A16-3760-4FAA-B547-27529032AFEA@freebsd.org> <521C4CE3.9080400@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 06:58:34 -0000 On Aug 27, 2013, at 8:53 AM, Andre Oppermann wrote: > On 27.08.2013 08:30, Michael Tuexen wrote: >> On Aug 27, 2013, at 7:53 AM, Hans Petter Selasky = wrote: >>=20 >>> 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. >> 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... >=20 > 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. Correct. There is the hidden assumption that there is no padding. Maybe = you can put that in a comment... We could also have some code (maybe under INVARIANTS) where we check = that an struct mbuf has the size MSIZE and panic if not. This would make things clearer if the problem happens again. >=20 >> 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. >=20 > 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. I completely agree... >=20 > --=20 > Andre >=20 >=20