patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
	Shahaf Shuler <shahafs@mellanox.com>
Cc: "Nélio Laranjeiro" <nelio.laranjeiro@6wind.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-stable] [PATCH v2] net/mlx5: fix link status query
Date: Thu, 2 Feb 2017 09:45:35 +0100	[thread overview]
Message-ID: <20170202084534.GT10133@6wind.com> (raw)
In-Reply-To: <963be495-c009-2937-5a14-204ae3a3b245@intel.com>

On Wed, Feb 01, 2017 at 06:11:17PM +0000, Ferruh Yigit wrote:
> 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@dpdk.org
> >>>>>>
> >>>>>> Signed-off-by: Shahaf Shuler <shahafs@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.

All right, turns out we're both wrong because it should have been >= anyway
regardless of the order as you pointed out. The block must appear when
kernel version is higher or equal to 4.9.0.

Now I think there are a couple of additional issues with this patch that
require a revert and rework:

- Kernel headers do not necessarily match the running version. What if this
  code is compiled against a 4.10.0 source tree and the running kernel is
  4.5? How about the reverse?

- By removing the check on ETHTOOL_GLINKSETTINGS, this code breaks
  compilation for Linux kernel version < 4.5, which I think is a problem.

So I believe this patch should be re-worked to maintain a check on
ETHTOOL_GLINKSETTINGS (or define it then not present) and perform an
additional version check at runtime to use the most appropriate ioctl API.

Ferruh, please revert.

stable@dpdk.org, please ignore this commit for the the time being, and sorry
for the noise.

> > 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,
> >>>>> <...>
> >>>
> >>
> > 
> 

-- 
Adrien Mazarguil
6WIND

  reply	other threads:[~2017-02-02  8:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-25 12:42 [dpdk-stable] [PATCH 1/2] " Shahaf Shuler
2017-01-30 15:25 ` Nélio Laranjeiro
2017-01-31 11:44 ` [dpdk-stable] [PATCH v2] " Shahaf Shuler
2017-01-31 11:45 ` Shahaf Shuler
2017-01-31 15:42   ` Nélio Laranjeiro
2017-02-01 18:31     ` Ferruh Yigit
2017-02-02  8:20       ` Nélio Laranjeiro
2017-02-02 10:18         ` Ferruh Yigit
2017-01-31 16:17   ` Ferruh Yigit
2017-02-01  6:53     ` Shahaf Shuler
2017-02-01  9:07       ` Adrien Mazarguil
2017-02-01 11:13         ` Ferruh Yigit
2017-02-01 12:57           ` Adrien Mazarguil
2017-02-01 18:11             ` Ferruh Yigit
2017-02-02  8:45               ` Adrien Mazarguil [this message]
2017-02-02 10:15                 ` Ferruh Yigit
2017-02-02 10:37                   ` Adrien Mazarguil
2017-02-02 10:43                     ` Ferruh Yigit
2017-02-09 12:29   ` [dpdk-stable] [PATCH v3] " Shahaf Shuler
2017-02-09 14:45     ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170202084534.GT10133@6wind.com \
    --to=adrien.mazarguil@6wind.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=nelio.laranjeiro@6wind.com \
    --cc=shahafs@mellanox.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).