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 8B5D0A0C4D; Thu, 17 Jun 2021 08:14:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0A5104067A; Thu, 17 Jun 2021 08:14:47 +0200 (CEST) Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by mails.dpdk.org (Postfix) with ESMTP id 5F29F40150 for ; Thu, 17 Jun 2021 08:14:46 +0200 (CEST) Received: from mail-qt1-f199.google.com ([209.85.160.199]) by youngberry.canonical.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1ltlIb-0000IH-T9 for dev@dpdk.org; Thu, 17 Jun 2021 06:14:45 +0000 Received: by mail-qt1-f199.google.com with SMTP id f13-20020ac85d0d0000b029024ba963cb08so3143577qtx.4 for ; Wed, 16 Jun 2021 23:14:45 -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=fQ20heDRxnbe4ZaXv/Br9yGcNpmzoms1paq81p1Lk2o=; b=S6KYDZu131a4wTBeDL/HYqYBqOmwNVy5JDIrmaJLwtFwPnmOeuRFlhIaxxX/9VpqpX qGmnjZOkNTpRhLv/kOLnpluJgGK7MRCYG8F2LuW+dXoFjSOvwx+9sSKojG/n5+bDw/TS hTS5jQSQwAi85xYQZ9XhXAQdI5mdtfeSmRc0q7Dyyg6oinApTQ0/CCYr39kdHRmDqktW R9Gq5OUHGm/6vyYhzQ8bmvnk5Ri9RYkdEuPDO3r4N73PUou21jJevXj+31j6X13M7izP bxiawqzYpeKWkIRmJ/dDEnNbNuIhu+gr1dZx8XIxMylQBTGmL5xgKrySy6afQeWLLTro YcjA== X-Gm-Message-State: AOAM532GmPqBSGhRfyoxzSlOE4BLvELCrTpiMf2Jf9ZaLtDIUuXArQBS eO7TLsjOmj02efyh3sHTyffYK23VgSkda+UZ5Wp+gqPtwZNqjHDx+oj4j3/PC6qNTUFQkkAf3T9 tNF316Lz5cOymBJu7aNZrIlOzg6mhLoLSAQ7q X-Received: by 2002:ac8:5708:: with SMTP id 8mr3509754qtw.112.1623910484981; Wed, 16 Jun 2021 23:14:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCEp7IB44DcDX5N7vInT6xySRNfKq0X7JOk5jWYy4/9PlHqszhQRgwAaz6hGNMu3lamcSosXnOGO2XRhAqygA= X-Received: by 2002:ac8:5708:: with SMTP id 8mr3509734qtw.112.1623910484733; Wed, 16 Jun 2021 23:14:44 -0700 (PDT) MIME-Version: 1.0 References: <20210602143317.2333707-1-christian.ehrhardt@canonical.com> <95714253-c0a5-9cbc-31ed-918e158c8109@intel.com> In-Reply-To: From: Christian Ehrhardt Date: Thu, 17 Jun 2021 08:14:18 +0200 Message-ID: To: Ferruh Yigit Cc: dev , Thomas Monjalon , dpdk stable , Thomas Bogendoerfer , "jcaamano@suse.com" , "snmohan83@gmail.com" , "ndas@suse.de" , Marco Varlese 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, 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. 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 > Now "my SLE15" fails > > [ 232s] /home/abuild/rpmbuild/BUILD/dpdk-1623314498.43b908fe8/x86_64-default-linux-gcc/build/kernel/linux/kni/kni_net.c:791:20: > error: initialization from incompatible pointer type > [-Werror=incompatible-pointer-types] > [ 232s] .ndo_tx_timeout = kni_net_tx_timeout, > [ 232s] ^~~~~~~~~~~~~~~~~~ > > The full log is at > https://build.opensuse.org/package/live_build_log/home:cpaelzer:branches:home:bluca:dpdk/dpdk-19.11/SLE_15/x86_64 > > That means now the check is now no more catching this SLE15 with their > linux-5.3.18-57. > > I need to find what SLE_VERSION_CODE really is in that environment :-/ > Sadly I don't have that system locally. > > So the V3 will be delayed, but any additional input is welcome. > > P.S. or I can't make an >= check on SLE_VERSION_CODE ...? > > > > > [1] > > > http://mails.dpdk.org/archives/test-report/2021-June/197571.html > > > > > > > --- > > > > kernel/linux/kni/compat.h | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/kernel/linux/kni/compat.h b/kernel/linux/kni/compat.h > > > > index 5f65640d5ed..70e014fd1da 100644 > > > > --- a/kernel/linux/kni/compat.h > > > > +++ b/kernel/linux/kni/compat.h > > > > @@ -133,7 +133,9 @@ > > > > > > > > #if KERNEL_VERSION(5, 6, 0) <= LINUX_VERSION_CODE || \ > > > > (defined(RHEL_RELEASE_CODE) && \ > > > > - RHEL_RELEASE_VERSION(8, 3) <= RHEL_RELEASE_CODE) > > > > + RHEL_RELEASE_VERSION(8, 3) <= RHEL_RELEASE_CODE) || \ > > > > + (defined(CONFIG_SUSE_KERNEL) && \ > > > > + KERNEL_VERSION(5, 3, 18) <= LINUX_VERSION_CODE) > > > > > > Can you please add comment here to clarify for which SUSE version this check is > > > added? > > > > I outlined that in the commit message already, and since the RH8.3 > > check above was added without inline comment I kept the same style. > > With the updated v3 it will be readable from the code as I'll try > > (SLE_VERSION_CODE >= SLE_VERSION(15, 3, 0) > > > > I'll submit the v3 after it has passed my test builds which include > > - SLE_12_SP4 > > - SLE_15 > > - openSUSE_Factory_ARM > > - openSUSE_Leap_15.2 > > - openSUSE_Leap_42.3 > > - openSUSE_Tumbleweed > > > > And of those SLE_15 was the one affected without this fix due to their > > new new kernel. > > > > > > #define HAVE_TX_TIMEOUT_TXQUEUE > > > > #endif > > > > > > > > > > > > > > > > > -- > > Christian Ehrhardt > > Staff Engineer, Ubuntu Server > > Canonical Ltd > > > > -- > Christian Ehrhardt > Staff Engineer, Ubuntu Server > Canonical Ltd -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd