From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42])
 by dpdk.org (Postfix) with ESMTP id 69E94804A
 for <dev@dpdk.org>; Tue,  9 Dec 2014 09:53:20 +0100 (CET)
Received: by mail-wg0-f42.google.com with SMTP id z12so182006wgg.29
 for <dev@dpdk.org>; Tue, 09 Dec 2014 00:53:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
 :cc:subject:references:in-reply-to:content-type
 :content-transfer-encoding;
 bh=SnGuJaKR6tAC9Ng+2lfJXfAJ1LGoUmR8BHhXPvFDbQg=;
 b=AAeXDyOIWBWPWtBHYCRTY5XOvFSHZS30Elnv+eUSYNa9EMGG8co857srYOMwKUkkW5
 bHKZCT3Vz6euS+/1+JlXo+czTztisPazmhVpiq1VYdGrXihYaCVfPuEInQkuGlVmWnqc
 wqvFXeBj3tSIiRbUOPQVrLlt7CkzF8WXNuGp+8sw+jvpXVuK55+hmpD0LWvV/+Pj3x64
 S2BSikpOmuYmEnT/Grh+bVtN+ECTFD3CSGD3ghvrpmiIc8YcLSpPAVgXP81PnzrBFQWZ
 394GMX1DrnoloBFHulYWGkZETvJFjCFonCAy6LTfmpxY0UcTAMucLZv01VHksBXbGhCa
 QQ+w==
X-Gm-Message-State: ALoCoQngc9ba6irg81UGup8PpyXRQJH+8ac4tiThuYVLnXr0cTnX7OejJdO8A9nU20inbxkXL4r/
X-Received: by 10.180.93.167 with SMTP id cv7mr2577513wib.12.1418115199567;
 Tue, 09 Dec 2014 00:53:19 -0800 (PST)
Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net.
 [82.239.227.177])
 by mx.google.com with ESMTPSA id o2sm799086wja.45.2014.12.09.00.53.18
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Tue, 09 Dec 2014 00:53:19 -0800 (PST)
Message-ID: <5486B87E.5010404@6wind.com>
Date: Tue, 09 Dec 2014 09:53:18 +0100
From: Olivier MATZ <olivier.matz@6wind.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Neil Horman <nhorman@tuxdriver.com>, Jia Yu <jyu@vmware.com>
References: <1415381289-43291-1-git-send-email-jyu@vmware.com>
 <20141208150401.GB3907@localhost.localdomain>
In-Reply-To: <20141208150401.GB3907@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Dec 2014 08:53:20 -0000

Hi Neil,

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 <jyu@vmware.com>
>>
> Why?  I presume there was a build break or something.  Please repost with a
> changelog that details what this patch is for.
> Neil

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:

	struct per_core_foo {
		...
	} __rte_cache_aligned;

	struct global_foo {
		struct per_core_foo foo[RTE_MAX_CORE];
	};

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

I have no idea about how we could prevent this issue, except using
__attribute__((aligned(CACHE_LINE))) instead of __rte_cache_aligned.

Anyway this could probably explain the willing to include rte_memory.h
everywhere.

Regards,
Olivier