[dpdk-dev] [PATCH] net/mlx5: fix bit field compiling error

Ferruh Yigit ferruh.yigit at intel.com
Thu Oct 29 15:28:04 CET 2020


On 10/26/2020 6:07 PM, Raslan Darawsheh wrote:
> Hi,
> 
> 
>> -----Original Message-----
>> From: Bing Zhao <bingz at nvidia.com>
>> Sent: Monday, October 26, 2020 7:25 PM
>> To: viacheslavo at mellanox.com; matan at mellanox.com
>> Cc: dev at dpdk.org; Ori Kam <orika at nvidia.com>; Raslan Darawsheh
>> <rasland at nvidia.com>; Andrey Vesnovaty <andreyv at nvidia.com>
>> Subject: [PATCH] net/mlx5: fix bit field compiling error
>>
>> Some old compilers and old specification will not support bit field
>> with other types except integer or unsigned integer.
>> Since the next and previous items are 64b and/or 32b aligned, bit
>> field with "unsigned char" type will not save any space and the
>> compiler will complain.
>> Changing it to "unsigned int" type bit field will solve the issue.
>>
>> Fixes: f711b60d400b ("net/mlx5: modify hash Rx queue objects")
>> Cc: andreyv at nvidia.com
>>
>> Signed-off-by: Bing Zhao <bingz at nvidia.com>
>> ---
>>   drivers/net/mlx5/mlx5.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
>> index c537af9..e5640c1 100644
>> --- a/drivers/net/mlx5/mlx5.h
>> +++ b/drivers/net/mlx5/mlx5.h
>> @@ -733,7 +733,7 @@ struct mlx5_ind_table_obj {
>>   struct mlx5_hrxq {
>>   	ILIST_ENTRY(uint32_t)next; /* Index to the next element. */
>>   	rte_atomic32_t refcnt; /* Reference counter. */
>> -	uint8_t shared:1; /* This object used in shared action. */
>> +	uint32_t shared:1; /* This object used in shared action. */
>>   	struct mlx5_ind_table_obj *ind_table; /* Indirection table. */
>>   	RTE_STD_C11
>>   	union {
>> --
>> 1.8.3.1
> 
> Patch squashed into relevant commit in next-net-mlx,
> 

Hi Raslan,

Updating patches that has been pulled by next-net makes very hard to pull your tree.

Can you please squash only ones that are still only in the mlx tree, for others 
I can update in the next-net which is easier than resolving conflicts on merge.

Thanks,
ferruh



More information about the dev mailing list