From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3257 invoked by alias); 4 Jul 2014 01:35:39 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 3188 invoked by uid 89); 4 Jul 2014 01:35:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL autolearn=no version=3.3.2 X-HELO: nm27-vm10.access.bullet.mail.bf1.yahoo.com Received: from nm27-vm10.access.bullet.mail.bf1.yahoo.com (HELO nm27-vm10.access.bullet.mail.bf1.yahoo.com) (216.109.115.233) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 04 Jul 2014 01:35:30 +0000 Received: from [66.196.81.164] by nm27.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jul 2014 01:35:28 -0000 Received: from [98.138.104.100] by tm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jul 2014 01:35:28 -0000 Received: from [127.0.0.1] by smtp120.sbc.mail.ne1.yahoo.com with NNFMP; 04 Jul 2014 01:35:27 -0000 X-Yahoo-SMTP: DAVHEHCswBBSt52LEL26uXq8GY.pd.0s2WK3iX0- X-Rocket-Received: from T23a.STS (lgm0@71.107.71.100 with plain [98.138.84.31]) by smtp120.sbc.mail.ne1.yahoo.com with SMTP; 04 Jul 2014 01:35:27 +0000 UTC Message-ID: <53B603D8.90807@verizon.net> Date: Fri, 04 Jul 2014 01:35:00 -0000 From: Les Miklosy User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: ecos-discuss@ecos.sourceware.org References: <539659A0.7070100@verizon.net> In-Reply-To: <539659A0.7070100@verizon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ECOS] The Alignment and Init of Ethernet Data Structures X-SW-Source: 2014-07/txt/msg00003.txt.bz2 This question regards the Ethernet drivers found in the devs/eth directory. I found the data structure for xxx_eth_info in these header files: fec.h, fcc.h, quicc_eth.h, ppc405_eth.h. Moab uses the ppc405_eth.h while Rattler uses the fcc.h. When the data structure xxx_eth_info is initialized, the Moab and Rattler configurations use data alignment constructs (the literature calls 'compound literals') while fec and quicc_eth do not. An example of the data alignment construct for Moab is: // Align buffers on a cache boundary #define RxBUFSIZE CYGNUM_DEVS_ETH_POWERPC_PPC405_RxNUM*CYGNUM_DEVS_ETH_POWERPC_PPC405_BUFSIZE #define TxBUFSIZE CYGNUM_DEVS_ETH_POWERPC_PPC405_TxNUM*CYGNUM_DEVS_ETH_POWERPC_PPC405_BUFSIZE static unsigned char ppc405_eth_rxbufs[RxBUFSIZE] __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); static unsigned char ppc405_eth_txbufs[TxBUFSIZE] __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); static mal_bd_t ppc405_eth_rxbd[CYGNUM_DEVS_ETH_POWERPC_PPC405_RxNUM] __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); static mal_bd_t ppc405_eth_txbd[CYGNUM_DEVS_ETH_POWERPC_PPC405_TxNUM] __attribute__((aligned(HAL_DCACHE_LINE_SIZE))); Why are these used in the cases of fcc and ppc405 but not for fec and quicc? Is the alignment necessary or recommended for new ports? What might be the consequences if alignment during initialization is not used? For other platforms are we relying on the compiler to rack-and-stack data structures properly on boundaries optimized by the compiler? Thanks for any guidance. Les -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss