From mboxrd@z Thu Jan  1 00:00:00 1970
From: Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [PATCH 10/36] mempool: use the list to iterate the
 mempool elements
Date: Fri, 15 Apr 2016 09:31:45 +0200
Message-ID: <571098E1.8090905@6wind.com>
References: <1457540381-20274-1-git-send-email-olivier.matz@6wind.com>
 <1460629199-32489-1-git-send-email-olivier.matz@6wind.com>
 <1460629199-32489-11-git-send-email-olivier.matz@6wind.com>
 <2D283F2F-17D1-4022-B95E-B1CF8526F526@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: "Richardson, Bruce" <bruce.richardson@intel.com>,
 "stephen@networkplumber.org" <stephen@networkplumber.org>
To: "Wiles, Keith" <keith.wiles@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Return-path: <dev-bounces@dpdk.org>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id 8E3234B79
 for <dev@dpdk.org>; Fri, 15 Apr 2016 09:31:53 +0200 (CEST)
In-Reply-To: <2D283F2F-17D1-4022-B95E-B1CF8526F526@intel.com>
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi,

On 04/14/2016 05:33 PM, Wiles, Keith wrote:
>>
>> static void
>> -txq_mp2mr_mbuf_check(void *arg, void *start, void *end,
>> -		     uint32_t index __rte_unused)
>> +txq_mp2mr_mbuf_check(struct rte_mempool *mp, void *arg, void *obj,
>> +	__rte_unused uint32_t index)
> 
> I have seen this use of __rte_unused or attributes attached to variables and structures in couple different ways.
> 
> I have seen the placement of the attribute after and before the variable I prefer the attribute to be after, but could adapt I hope.
> Do we have a rule about where the attribute is put in this case and others. I have seen the attributes for structures are always at the end of the structure, which is some cases it may not compile in other places.
> 
> I would like to suggest we place the attributes at the end of structure e.g. __rte_cached_aligned and I would like to see the __rte_unused after the variable as a style in the code.

I agree the __rte_unused shouldn't have moved in this patch.

About the default place of attributes, I've seen an exemple where
putting it at the end didn't what I expected:

	struct {
		int foo;
	} __rte_cache_aligned;

The expected behavior is to define a structure which is cache aligned.
But if "rte_memory.h" is not included, it will define a structure which
is not cache aligned, and a global variable called __rte_cache_aligned,
without any compiler warning.

The gcc doc gives some hints about where to place the attributes:
https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html

Given its length, I'm not sure the dpdk coding rules should contain
anything more than "refer to gcc documentation" ;)

Regards,
Olivier