From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 06:53:29 2013 Return-Path: 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 26D0E2CB for ; Tue, 27 Aug 2013 06:53:29 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B7162FB0 for ; Tue, 27 Aug 2013 06:53:28 +0000 (UTC) Received: (qmail 11753 invoked from network); 27 Aug 2013 07:35:31 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2013 07:35:31 -0000 Message-ID: <521C4CE3.9080400@freebsd.org> Date: Tue, 27 Aug 2013 08:53:23 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael Tuexen Subject: Re: ARM network trouble after recent mbuf changes 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> In-Reply-To: <3F762A16-3760-4FAA-B547-27529032AFEA@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:53:29 -0000 On 27.08.2013 08:30, Michael Tuexen wrote: > On Aug 27, 2013, at 7:53 AM, 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. >> >> >> 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