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.ehrha...@canonical.com> wrote:
On Thu, Jun 10, 2021 at 10:39 AM Christian Ehrhardt
<christian.ehrha...@canonical.com> wrote:
On Tue, Jun 8, 2021 at 1:17 PM Ferruh Yigit <ferruh.yi...@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 <tbogendoer...@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: sta...@dpdk.org
Signed-off-by: Christian Ehrhardt <christian.ehrha...@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.
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.
