From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 13:25:12 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 C08CEC2B for ; Tue, 27 Aug 2013 13:25:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B65D2752 for ; Tue, 27 Aug 2013 13:25:12 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id aq17so7491116iec.27 for ; Tue, 27 Aug 2013 06:25:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=g/NjVfgm13EwwWvDKFx6xeLJYqvYhVNcFTIFysQCHoE=; b=baT/bQkORjs/CoeidDEPyAId0GOlkBc/SmKbOLSzEPc7CTda4CBw9qUolOfs/XqBxD hmenZ5w2GWHeHartqrns1V6vQIXs0sUgIpICWANi9nxKseBZzW0tVljtfsaJ/6SHAoQm F2WDGkbY0Gm6Vboi3bX5YY7x+pTgIDZG2O5Gc+MQWjCgBDt7Asj4IXuOR3iGwZRLK2hQ Z6AS/+ufeMtYyrjuqVhW2KL+00/nGeNvy4JYSLKJa/bIVuLxwDl2WhGabCkNN77v3iaX uFjtokZTdSml6htmg5Nzk7tc3HerHq/xvXkfEdahoAH2BBizlRn4t2/2wTLQI/cHnb+O nSbw== X-Gm-Message-State: ALoCoQli+TX9CBSfZUDDTeNyJ/Jm+Mzj005Fa8dVxSR+YK1gMTW8OaIRJdr2MS/I5Q2zw4bNft28 X-Received: by 10.42.52.129 with SMTP id j1mr10092566icg.5.1377609906311; Tue, 27 Aug 2013 06:25:06 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id w4sm24365505igb.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 06:25:05 -0700 (PDT) Sender: Warner Losh Subject: Re: ARM network trouble after recent mbuf changes Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <627451FE-4F20-4E4D-9B24-59E0F340EF75@freebsd.org> Date: Tue, 27 Aug 2013 07:25:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <627451FE-4F20-4E4D-9B24-59E0F340EF75@freebsd.org> To: Michael Tuexen X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm , Andre Oppermann 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 13:25:12 -0000 On Aug 27, 2013, at 12:58 AM, Michael Tuexen wrote: > On Aug 27, 2013, at 8:53 AM, Andre Oppermann = wrote: >=20 >> 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... Maybe we can have it as a CTASSERT. Better than any comment. CTASSERTS = are free and catch this kind of thing... > 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 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"