From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6B5A0A0A0F for ; 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 ; 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 ) 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 ; 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> <1708042.2qKnxoAoZE@thomas> <06e1242e-5970-36e9-cb0a-358639168616@suse.com> In-Reply-To: <06e1242e-5970-36e9-cb0a-358639168616@suse.com> From: Christian Ehrhardt Date: Thu, 1 Jul 2021 10:23:44 +0200 Message-ID: To: Marco Varlese Cc: Thomas Monjalon , Ferruh Yigit , dev , dpdk stable , Thomas Bogendoerfer , "jcaamano@suse.com" , "snmohan83@gmail.com" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Thu, Jun 17, 2021 at 10:25 AM Marco Varlese 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 > >> wrote: > >>> On Thu, Jun 10, 2021 at 10:39 AM Christian Ehrhardt > >>> wrote: > >>>> On Tue, Jun 8, 2021 at 1:17 PM Ferruh Yigit 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 > >>>>>> 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 > >>>>> 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