[dpdk-dev] [dpdk-stable] [PATCH v2] net/mlx5: fix link status query

Ferruh Yigit ferruh.yigit at intel.com
Wed Feb 1 19:11:17 CET 2017


On 2/1/2017 12:57 PM, Adrien Mazarguil wrote:
> On Wed, Feb 01, 2017 at 11:13:59AM +0000, Ferruh Yigit wrote:
>> On 2/1/2017 9:07 AM, Adrien Mazarguil wrote:
>>> On Wed, Feb 01, 2017 at 06:53:55AM +0000, Shahaf Shuler wrote:
>>>> : Tuesday, January 31, 2017 6:17 PM, Ferruh Yigit:
>>>>> On 1/31/2017 11:45 AM, Shahaf Shuler wrote:
>>>>>> Trying to query the link status through new kernel ioctl API
>>>>>> ETHTOOL_GLINKSETTINGS was always failing due to kernel bug.
>>>>>> The bug was fixed on version 4.9
>>>>>> this patch uses the legacy ioctl API for lower kernels.
>>>>>>
>>>>>> Fixes: 188408719888 ("net/mlx5: fix support for newer link speeds")
>>>>>> CC: stable at dpdk.org
>>>>>>
>>>>>> Signed-off-by: Shahaf Shuler <shahafs at mellanox.com>
>>>>>> ---
>>>>>
>>>>> <...>
>>>>>
>>>>>> @@ -707,7 +708,7 @@ struct priv *
>>>>>>  static int
>>>>>>  mlx5_link_update_unlocked_gs(struct rte_eth_dev *dev, int
>>>>>> wait_to_complete)  { -#ifdef ETHTOOL_GLINKSETTINGS
>>>>>> +#if KERNEL_VERSION(4, 9, 0) <= LINUX_VERSION_CODE
>>>>>
>>>>> Mostly it is not good idea to do kernel version check in the .c file.
>>>>>
>>>>> It is possible to move this comparison to the .h file, and set a feature
>>>>> macro based on comparison result, like HAVE_ETHTOOL_GLINKSETTINGS,
>>>>> and
>>>>> use this macro in the .c file.
>>>>>
>>>>> This makes .c code easier to understand. And the abstraction in the
>>>>> header file lets you update the comparison in the future without
>>>>> changing the code itself.
>>>>>
>>>>> But it is your call, do you prefer to continue with this one?
>>>>
>>>> This is a good suggestion. 
>>>> Adrien, Nélio what do you think?
>>>
>>> Let's include this patch as-is. Doing so in a header file such as mlx5.h
>>> would require including linux/version.h from that file and cause the entire
>>> PMD to be even more OS-dependent.
>>>
>>> We'll move this check elsewhere in the future if we need several such
>>> workarounds, thanks.
>>
>> OK.
>>
>> One more thing, comment log says:
>> "The bug was fixed on version 4.9"
>>
>> And code does:
>> "+#if KERNEL_VERSION(4, 9, 0) <= LINUX_VERSION_CODE"
>>
>> If the bug is fixed in 4.9, should check be "<" instead of "<="
> 
> I'll concede the argument order used in this condition is somewhat unusual
> but it actually ends up being the same as:
> 
>  #if LINUX_VERSION_CODE > KERNEL_VERSION(4, 9, 0)

I don't think they are same, unless I am missing something obvious.

"+#if KERNEL_VERSION(4, 9, 0) <= LINUX_VERSION_CODE"
vs
"#if LINUX_VERSION_CODE > KERNEL_VERSION(4, 9, 0)"

Even if you change the argument order, one covers 4.9 release other not.

> 
> Which is the correct intent. I guess you can update this line for clarity if
> you think it's necessary.

If the intention is as following, I can fix it while applying:
#if KERNEL_VERSION(4, 9, 0) < LINUX_VERSION_CODE

> 
>>>
>>>>>>  	struct priv *priv = mlx5_get_priv(dev);
>>>>>>  	struct ethtool_link_settings edata = {
>>>>>>  		.cmd = ETHTOOL_GLINKSETTINGS,
>>>>> <...>
>>>
>>
> 



More information about the dev mailing list