From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by dpdk.org (Postfix) with ESMTP id 4E4587E23 for ; Wed, 10 Dec 2014 20:08:28 +0100 (CET) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 886FA291FB; Wed, 10 Dec 2014 11:08:26 -0800 (PST) Received: from EX13-CAS-004.vmware.com (EX13-CAS-004.vmware.com [10.113.191.54]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 82B16B10B8; Wed, 10 Dec 2014 11:08:26 -0800 (PST) Received: from EX13-MBX-019.vmware.com (10.113.191.39) by EX13-MBX-001.vmware.com (10.113.191.21) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 10 Dec 2014 11:08:19 -0800 Received: from EX13-MBX-018.vmware.com (10.113.191.38) by EX13-MBX-019.vmware.com (10.113.191.39) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 10 Dec 2014 11:08:00 -0800 Received: from EX13-MBX-018.vmware.com ([fe80::7cdc:b1ba:f507:8b02]) by EX13-MBX-018.vmware.com ([fe80::7cdc:b1ba:f507:8b02%15]) with mapi id 15.00.0913.011; Wed, 10 Dec 2014 11:09:03 -0800 From: Jia Yu To: Neil Horman , Olivier MATZ Thread-Topic: [dpdk-dev] lib: include rte_memory.h for __rte_cache_aligned Thread-Index: AQHQEvhzYMLEPOj5i0yXp5tnw6bPhpyHe1IAgABsnwCAAUtPAA== Date: Wed, 10 Dec 2014 19:09:03 +0000 Message-ID: References: <1415381289-43291-1-git-send-email-jyu@vmware.com> <20141208150401.GB3907@localhost.localdomain> <5486B87E.5010404@6wind.com> <20141209152204.GD28871@hmsreliant.think-freely.org> In-Reply-To: <20141209152204.GD28871@hmsreliant.think-freely.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.113.160.246] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] lib: include rte_memory.h for __rte_cache_aligned X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 19:08:28 -0000 Hi Neil, Moving __rte_cache_aligned right after struct keyword will help. On the other hand, enforcing this rule for existing (100+) and future definitions will be difficult. It=B9s clearer and a good practice to include header fil= e explicitly. Thanks, Jia On 12/9/14, 7:22 AM, "Neil Horman" wrote: >On Tue, Dec 09, 2014 at 09:53:18AM +0100, Olivier MATZ wrote: >> Hi Neil, >>=20 >> On 12/08/2014 04:04 PM, Neil Horman wrote: >> >On Fri, Nov 07, 2014 at 09:28:09AM -0800, Jia Yu wrote: >> >>Include rte_memory.h for lib files that use __rte_cache_aligned >> >>attribute. >> >> >> >>Signed-off-by: Jia Yu >> >> >> >Why? I presume there was a build break or something. Please repost >>with a >> >changelog that details what this patch is for. >> >Neil >>=20 >> I don't know if Yu's issue was the same, but I had a very "fun" issue >> with __rte_cache_aligned in my application. Consider the following code: >>=20 >> struct per_core_foo { >> ... >> } __rte_cache_aligned; >>=20 >> struct global_foo { >> struct per_core_foo foo[RTE_MAX_CORE]; >> }; >>=20 >> If __rte_cache_aligned is not defined (rte_memory.h is not included), >> the code compiles but the structure is not aligned... it defines the >> structure and creates a global variable called __rte_cache_aligned. >> And this can lead to really bad things if this code is in a .h that >> is included by files that may or may not include rte_memory.h >>=20 >> I have no idea about how we could prevent this issue, except using >> __attribute__((aligned(CACHE_LINE))) instead of __rte_cache_aligned. >>=20 >> Anyway this could probably explain the willing to include rte_memory.h >> everywhere. >>=20 >> Regards, >> Olivier >>=20 >>=20 > >So, that is a great explination, and would be good to have in the >changelog. > >Also, to avoid the problem that you describe, while its preferred to have >it at >the end of a struct, you can also put the alignment attribute right after >the >struct keyword in gcc: >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__gcc.gnu.org_onlined= oc >s_gcc_Attribute-2DSyntax.html-23Attribute-2DSyntax&d=3DAAIBAg&c=3DSqcl0Ez6= M0X8 >aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=3Dq34pQj5yiMxs5OseYCxXLQ&m=3DmIyHF3ASZxR= mbPs >acyMyIABQlSafUdV9PqknKAtfOuI&s=3DpKoAAkIYRX31K-gR5oSwpcA5mLj4nG7uEzyh0z_uw= xU >&e=3D=20 > >That seems like it would solve the problem going forward. > >Neil >