From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 6B5A0A0A0F
for <public@inbox.dpdk.org>; Thu, 1 Jul 2021 10:24:13 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 5DDC1412B3;
Thu, 1 Jul 2021 10:24:13 +0200 (CEST)
Received: from youngberry.canonical.com (youngberry.canonical.com
[91.189.89.112]) by mails.dpdk.org (Postfix) with ESMTP id A69F540141
for <stable@dpdk.org>; Thu, 1 Jul 2021 10:24:11 +0200 (CEST)
Received: from mail-qk1-f200.google.com ([209.85.222.200])
by youngberry.canonical.com with esmtps (TLS1.2) tls
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93)
(envelope-from <christian.ehrhardt@canonical.com>)
id 1lyrzX-00044w-1G
for stable@dpdk.org; Thu, 01 Jul 2021 08:24:11 +0000
Received: by mail-qk1-f200.google.com with SMTP id
o189-20020a378cc60000b02903b2ccd94ea1so3670907qkd.19
for <stable@dpdk.org>; Thu, 01 Jul 2021 01:24:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=oHBbnpnRAvqX6RAbtAm4R8KOgMX1f0WhdYXjZz/iedc=;
b=tEywTuwBWaoSzx3hClqDSu/xx/tLuTuhnbn/VtvAbJw2hWT6fYAdHDgnHzdGVDvMW/
fDc3axJwMnPA+o3DJwwa4P0AXLVAfm1+XE2XUBdd95ShehVIqkd/rg3wDm7+b7cpD93O
toUgysX3u4XHfg3vxomLYekHT0OPvOKwbvxcRh1h2CzOv9RnudwQq6I36KFEHsSEFTow
TvDnY1vt9ON3H3cex1DwuRBtWvKrbJMMSG2Qw0w6WQtCkzFc4/JwaqI4953M0mXPzcpD
ZHU1h9Cgq6zo4fED2Pfh8K3ihHWz6gFB9QYe5gWaeMM5pNGsxztT8z+zSH3uVgWUOzS/
AWNA==
X-Gm-Message-State: AOAM532LIWBzFh2kKGfKsINCkTz3hgtjhcht+dFM5ZbAEOX24pF2Bnqa
kpIug5ct+PFW0xkFFss4dkr7BNY2Lnnmp6TBE0SMFGsmimj/p+E0gMTJijYhchrzQB0IKCpoSM2
RLJcEUE9M6kIZvccsbPfR5isz31sppIquiXzGIVnf
X-Received: by 2002:ac8:75d5:: with SMTP id z21mr27116161qtq.7.1625127850122;
Thu, 01 Jul 2021 01:24:10 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJx6lKOE6io2AhugA9ct9u99EJHuoIzCqaqHetCfgIdQDAEfABUUFzUEKF8MhDCF6jakFSffBR9UKsuDICFtM3g=
X-Received: by 2002:ac8:75d5:: with SMTP id z21mr27116150qtq.7.1625127849863;
Thu, 01 Jul 2021 01:24:09 -0700 (PDT)
MIME-Version: 1.0
References: <20210602143317.2333707-1-christian.ehrhardt@canonical.com>
<CAATJJ0JoyRY=c2_u-Ty19Ek2=fUy0dN2_dWz6KUE1Oqd_JD=0Q@mail.gmail.com>
<CAATJJ0KeOY0GZ34KX9N-cX2oQt4=9TBuLrSN5iJORLP+TV3RgQ@mail.gmail.com>
<1708042.2qKnxoAoZE@thomas> <06e1242e-5970-36e9-cb0a-358639168616@suse.com>
In-Reply-To: <06e1242e-5970-36e9-cb0a-358639168616@suse.com>
From: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Date: Thu, 1 Jul 2021 10:23:44 +0200
Message-ID: <CAATJJ0+XK0j6tUp0bTnyZySQSuFGxTa13OqdxCGPYXFR6tumcQ@mail.gmail.com>
To: Marco Varlese <marco.varlese@suse.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
Ferruh Yigit <ferruh.yigit@intel.com>, dev <dev@dpdk.org>,
dpdk stable <stable@dpdk.org>, Thomas Bogendoerfer <tbogendoerfer@suse.de>,
"jcaamano@suse.com" <jcaamano@suse.com>,
"snmohan83@gmail.com" <snmohan83@gmail.com>, "ndas@suse.de" <ndas@suse.de>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [dpdk-stable] [PATCH] kni: fix compilation on SLES15-SP3
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
Sender: "stable" <stable-bounces@dpdk.org>
On Thu, Jun 17, 2021 at 10:25 AM Marco Varlese <marco.varlese@suse.com> wrote:
>
> Hello,
>
> On 6/17/21 8:41 AM, Thomas Monjalon wrote:
> > 17/06/2021 08:14, Christian Ehrhardt:
> >> On Thu, Jun 10, 2021 at 12:30 PM Christian Ehrhardt
> >> <christian.ehrhardt@canonical.com> wrote:
> >>> On Thu, Jun 10, 2021 at 10:39 AM Christian Ehrhardt
> >>> <christian.ehrhardt@canonical.com> wrote:
> >>>> On Tue, Jun 8, 2021 at 1:17 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >>>>> On 6/2/2021 3:33 PM, Christian Ehrhardt wrote:
> >>>>>> Like what was done for mainline kernel in commit 38ad54f3bc76 ("kni: fix
> >>>>>> build with Linux 5.6"), a new parameter 'txqueue' has to be added to
> >>>>>> 'ndo_tx_timeout' ndo on SLES 15-SP3 kernel.
> >>>>>>
> >>>>>> Caused by:
> >>>>>> commit c3bf155c40e9db722feb8a08c19efd44c12d5294
> >>>>>> Author: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> >>>>>> Date: Fri Sep 11 16:08:31 2020 +0200
> >>>>>> - netdev: pass the stuck queue to the timeout handler
> >>>>>> (jsc#SLE-13536).
> >>>>>> - Refresh patches.suse/sfc-move-various-functions.patch.
> >>>>>>
> >>>>>> That is part of the SLES 5.3.18 kernel and therefore the
> >>>>>> version we check for.
> >>>>>>
> >>>>>> Cc: stable@dpdk.org
> >>>>>>
> >>>>>> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> >>>>> Hi Christian,
> >>>>>
> >>>>> There is a build error reported in CI [1] with 'SUSE15-64'.
> >>>>> Can't the check 'linux version >= 5.3.18" may hit multiple SUSE versions, with
> >>>>> some has the patch mentioned above backported and some did not?
> >>>>> Can 'SLE_VERSION_CODE' be used to differentiate the SUSE versions?
> >>>> I don't have a perfect insight in the SUSE distro variants and their
> >>>> kernel versions.
> >>>>> 5.3.18 in SLES15-SP3 was what broke it and I have hoped that this would apply in general.
> >>>> But the error above seems we have others that are > 5.3.18 but at the
> >>>> same time not have the backport.
> >>>>
> >>>> I'll try to create a v3, but do we have anyone from Suse to usually
> >>>> directly ping for feedback on this?
> >>> With the new version (not submitted since it fails me) you can have a
> >>> look at my personal WIP branch:
> >>> => https://github.com/cpaelzer/dpdk-stable-queue/commit/43b908fe83e9cd68b08e259c0ace26ec692bb737
> >> Hello everyone,
> >> Ferruh and I reached out to the Suse people working on DPDK in the
> >> past as well as those doing the kernel backport that breaks it now.
> >> (I'll add them to CC here as well)
> >> Unfortunately there was no feedback in a week, but OTOH I also don't
> >> want to stall releases for too long due to this.
> >>
> >> I'll try to summarize the current understanding of this case again
> >>
> >> [1] breaks our KNI build.
> >>
> >> SLE_VERSION isn't provided by their Kernel; it is in DPDKs
> >> kernel/linux/kni/compat.h and not further maintained for a while.
> >> So we can't differentiate SLE15SP2 vs SLE15SP3 via that.
> >>
> >> The offending change was introduced in their kernel by [1]
> >> $ git tag --contains c3bf155c40e9 | sort | head
> >> rpm-5.3.18-24
> >> ...
> >>
> >> But checking just the kernel version 5.3.18 (as my initial patch had)
> >> won't work either.
> >> The problem is that this only checks the three levels of kernel
> >> version, but not the packaging level.
> >> And to make things even more fun, while I don't know if opensuse leap
> >> has the patch applied or not atm, but the kernel version there might
> >> make this even more complex as it is 5.3.18-lp152 at the moment.
> >>
> >> We have now:
> >> SLE15 SP2 5.3.18-22
> >> SLE15 SP3 5.3.18-57 (>=24)
> >> opensuse_leap 5.3.18-lp152
> >>
> >> Without a change SLE15SP3 is broken due to that backport.
> >> By checking on >=5.3.18 we could fix SP3, but break SP2 and maybe opensuse_leap.
> >>
> >> Maybe there is something on LOCALVERSION/EXTRAVERSION we can use, but
> >> "guessing" how the Suse kernel behaves isn't a good approach.
>
> You could try using these:
>
> -- CONFIG_SUSE_VERSION
>
> -- CONFIG_SUSE_PATCHLEVEL
>
> for your build-time dependencies.
>
> It's as fragile as the approach of using KERNEL_VERSION but it might
> help with the current issue.
Hi Marco,
my inbox has hidden this answer for a while :-/
What would the expected content of these be for the three kernels in my example?
SLE15 SP2 5.3.18-22
SLE15 SP3 5.3.18-57
opensuse_leap 5.3.18-lp152
I don't have all (any TBH) of those environments, so knowing what
values to expect will help to write the checks.
>
> >> Once Suse lets us know how to better differentiate their packaging
> >> version we can reconsider a proper fix for this.
> >>
> >> But without further input from Suse I'd (for now) ask to keep things
> >> as is (= not applying my patch).
> >> Due to that it will build in the same places it has built in the past.
> >> If we find a solution it can be in the next release in ~3 months, but
> >> I'll not further stall e.g. 19.11.9 that I'm working on right now.
> >>
> >> [1]: https://github.com/SUSE/kernel/commit/c3bf155c40e9
> > Thank you for the summary.
> >
> > This explains well why we should stop supporting KNI.
> >
> >
>
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd