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 D0832A0C4E; Mon, 25 Oct 2021 21:59:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 981A540E3C; Mon, 25 Oct 2021 21:59:31 +0200 (CEST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mails.dpdk.org (Postfix) with ESMTP id 36F0E4003E; Mon, 25 Oct 2021 21:59:30 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id C58CA320211E; Mon, 25 Oct 2021 15:59:28 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 25 Oct 2021 15:59:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= 0XVi51sNjC/aIKJhb0WubzaAVPY/rWH97Ra17Al5pgQ=; b=po9EOngNBGcCg9Oi 2FWyX1YiSICKLnin+LuzmD01lot6yy0tYKCi0kjmZ+5o4619ZWWxYx7WeWsh8uBV XioTOxpO+BVSov331OSEUxCZDXzYZ+Sf5edsJ5EFsQXxeDXVefXll14SZGzjdZwk kNXOc/OAq915c1SXo+X5pZ0f7VO7RhdkPbCdf1r1IHPxncdMnqUyUwrRr5sWSBo6 FgP6zNratVSNxi1tRjTQSbk9QDYCP98i/qyPAcT9JtFat7Q6RaK4zGOmH3poyZtG VU3eoaVmpvh8ful2rFdMhss4GbGfRZMIOBHfjrLkorQPlGHbvd2ORMeuPZF2keYP 3xQNag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=0XVi51sNjC/aIKJhb0WubzaAVPY/rWH97Ra17Al5p gQ=; b=CZiHWXNId98/J5iail0CuUs/b5GpEAoiH0P5G2Npyw0+6fR+6aelrVBPi Ae26TtGxGFjP3IJFRQBaR5lT5ovk/BRl7g8v7faYhseSO5Wf/cqvl+1+2sDR2lgl PXvHnTgZpAtbtfive/Q5L7pCpIV2AOIkjzVfbsqx/toApJD2TQE+BOnxjNHsZdJk MASiukyEOdWiONcrZiBfLhng+ZfFPUmWZ22FdJxhlgsZmGX4nEUOOKgCk7OzBUbd YHNKu516ZsHEiab2xuML6kXQdjj+Ic6YNOEHWi3MjgaUeYURviVfcdSy59WRwkb9 KwfnGnYc9f4FlJC7p6mJAo4RKajZw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdefhedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepkeejueekueevvefgfffggfehjeffvdefleejtdffudfgteejkeeg vddtvdffgfevnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpughpughkrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhm rghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 Oct 2021 15:59:25 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit , Christian Ehrhardt Cc: Marco Varlese , stable@dpdk.org, dev , Thomas Bogendoerfer , "jcaamano@suse.com" , "snmohan83@gmail.com" , "ndas@suse.de" , Aman Singh Date: Mon, 25 Oct 2021 21:59:24 +0200 Message-ID: <2731950.kRDzoTWeOm@thomas> In-Reply-To: References: <20210602143317.2333707-1-christian.ehrhardt@canonical.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-stable] [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" 01/07/2021 15:24, Christian Ehrhardt: > On Thu, Jul 1, 2021 at 10:23 AM Christian Ehrhardt > wrote: > > On Thu, Jun 17, 2021 at 10:25 AM Marco Varlese wrote: > > > 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. This has been fixed with an explicit check of the API: https://git.dpdk.org/dpdk/commit/?id=c28e2165ec360c39e