From owner-freebsd-arm@FreeBSD.ORG  Tue Aug 27 06:30:32 2013
Return-Path: <owner-freebsd-arm@FreeBSD.ORG>
Delivered-To: freebsd-arm@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 39B4BC82;
 Tue, 27 Aug 2013 06:30:32 +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 C07C52E7A;
 Tue, 27 Aug 2013 06:30:31 +0000 (UTC)
Received: from [192.168.1.200] (p508F3337.dip0.t-ipconnect.de [80.143.51.55])
 (Authenticated sender: macmic)
 by mail-n.franken.de (Postfix) with ESMTP id 4FF7C1C0C0692;
 Tue, 27 Aug 2013 08:30:28 +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 <tuexen@freebsd.org>
In-Reply-To: <521C3EE4.80801@bitfrost.no>
Date: Tue, 27 Aug 2013 08:30:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: Hans Petter Selasky <hps@bitfrost.no>
X-Mailer: Apple Mail (2.1508)
Cc: freebsd-arm <freebsd-arm@FreeBSD.org>, Andre Oppermann <andre@freebsd.org>
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to the StrongARM Processor <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2013 06:30:32 -0000

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.
>=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...

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.

Best regards
Michael
>=20
> --HPS
>=20
>=20