[dpdk-dev] [PATCH 10/36] mempool: use the list to iterate the mempool elements

Olivier Matz olivier.matz at 6wind.com
Fri Apr 15 09:31:45 CEST 2016


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


More information about the dev mailing list