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 A5770A0A0C; Thu, 1 Jul 2021 15:24:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 01D75412D9; Thu, 1 Jul 2021 15:24:39 +0200 (CEST) Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by mails.dpdk.org (Postfix) with ESMTP id C800C4067C for ; Thu, 1 Jul 2021 15:24:37 +0200 (CEST) Received: from mail-qt1-f197.google.com ([209.85.160.197]) by youngberry.canonical.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lywgH-0005ZE-50 for dev@dpdk.org; Thu, 01 Jul 2021 13:24:37 +0000 Received: by mail-qt1-f197.google.com with SMTP id u18-20020a05622a1992b029024f5f5d3a48so3325544qtc.2 for ; Thu, 01 Jul 2021 06:24:37 -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=50lKHrZAfi8peTAZPKBePxvBygMO06te3AUragwymAE=; b=qi/On+jXuLzeN8snjSgpLpjeXsgIebyluC7iViDbW3NyzPejebJ3z3RtNM2XbDZvb/ Zcek4z9ItRiYgoOUfSDcEx4Elbkl6T0QkuMf4lK6GVLyzflqUtupn+Txa8VyaQeqEO3t 5Sxr9SodKgYeHk3MtH5+xP+Dn6Wfv8W7nBHEOk7F6R7Sal6591l/zgZeTqaPaAQm7hPS PYnUDd1uLq7T0NoNXmL+ZKltxQ4X43nyKlmI03JRVt5p1cCDp4QAwgdVCbyWitO+TObx hXh6TFyI/kJtSUvDD5LUYtibUZGJWEBeoF8P8xeOJzCCrE92pbdGTChSJDI5Avf4GC3f dZCA== X-Gm-Message-State: AOAM532g8R6YSFdBIOSxAHlpncVTnOfP5uSev27CS62fjrivl8wRDjyN J9U50DEFqVHdfUBJpEuu1d/510CI//t7VcMTO8X1uChM9/p8ooxyoWhIfwbW0cEEWWEziVBts3t tpQl5xmpFKr4Q2bT3yWEjTVIH5YCSxGO+NaNg X-Received: by 2002:ac8:5708:: with SMTP id 8mr10392qtw.112.1625145876285; Thu, 01 Jul 2021 06:24:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz++l9ANLjnwLSgLLCUnE78P2UY7yj5SjgvVN45SwG57SQNZeTt6gBpA7dXAsVE9GdnbGL1d1eTwIuv268uJjA= X-Received: by 2002:ac8:5708:: with SMTP id 8mr10368qtw.112.1625145876002; Thu, 01 Jul 2021 06:24:36 -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: From: Christian Ehrhardt Date: Thu, 1 Jul 2021 15:24:09 +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-dev] [PATCH] kni: fix compilation on SLES15-SP3 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Jul 1, 2021 at 10:23 AM Christian Ehrhardt wrote: > > 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 In your kernel source I saw that this would match the "15" and "3" in SLES15SP3. But while that could help to differentiate SLE15 SP2 5.3.18-22 SLE15 SP3 5.3.18-57 But opensuse_leap 5.3.18-lp152 would have CONFIG_SUSE_VERSION 15 and CONFIG_SUSE_PATCHLEVEL 3 as well but AFAICS not have the patch in the kernel that changes this behavior. So I'm unsure on this ... maybe this needs a full step in the config that tries both definition styles. Depending on that outcome it can then use the new/old style. > 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 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd