diff mbox series

kni: fix compilation on SLES15-SP3

Message ID 20210602143317.2333707-1-christian.ehrhardt@canonical.com (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers
Series kni: fix compilation on SLES15-SP3 |

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/Intel-compilation fail Compilation issues
ci/intel-Testing success Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/github-robot success github build: passed
ci/iol-abi-testing success Testing PASS
ci/iol-testing success Testing PASS

Commit Message

Christian Ehrhardt June 2, 2021, 2:33 p.m. UTC 
  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 <tbogendoerfer@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: stable@dpdk.org

Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
---
 kernel/linux/kni/compat.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Luca Boccassi June 4, 2021, 1:02 p.m. UTC | #1 
On Wed, 2021-06-02 at 16:33 +0200, 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 <tbogendoerfer@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: stable@dpdk.org
> 
> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> ---
>  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)
>  #define HAVE_TX_TIMEOUT_TXQUEUE
>  #endif
> 

Acked-by: Luca Boccassi <bluca@debian.org>
Ferruh Yigit June 8, 2021, 11:17 a.m. UTC | #2 
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 <tbogendoerfer@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: stable@dpdk.org
> 
> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@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?


[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?

>  #define HAVE_TX_TIMEOUT_TXQUEUE
>  #endif
>  
>
Christian Ehrhardt June 10, 2021, 8:39 a.m. UTC | #3 
On Tue, Jun 8, 2021 at 1:17 PM Ferruh Yigit <ferruh.yigit@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 <tbogendoerfer@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: stable@dpdk.org
> >
> > Signed-off-by: Christian Ehrhardt <christian.ehrhardt@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?

> [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 June 10, 2021, 10:30 a.m. UTC | #4 
On Thu, Jun 10, 2021 at 10:39 AM Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
>
> On Tue, Jun 8, 2021 at 1:17 PM Ferruh Yigit <ferruh.yigit@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 <tbogendoerfer@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: stable@dpdk.org
> > >
> > > Signed-off-by: Christian Ehrhardt <christian.ehrhardt@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

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 June 17, 2021, 6:14 a.m. UTC | #5 
On Thu, Jun 10, 2021 at 12:30 PM Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
>
> On Thu, Jun 10, 2021 at 10:39 AM Christian Ehrhardt
> <christian.ehrhardt@canonical.com> wrote:
> >
> > On Tue, Jun 8, 2021 at 1:17 PM Ferruh Yigit <ferruh.yigit@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 <tbogendoerfer@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: stable@dpdk.org
> > > >
> > > > Signed-off-by: Christian Ehrhardt <christian.ehrhardt@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.
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
Thomas Monjalon June 17, 2021, 6:41 a.m. UTC | #6 
17/06/2021 08:14, Christian Ehrhardt:
> On Thu, Jun 10, 2021 at 12:30 PM Christian Ehrhardt
> <christian.ehrhardt@canonical.com> wrote:
> > On Thu, Jun 10, 2021 at 10:39 AM Christian Ehrhardt
> > <christian.ehrhardt@canonical.com> wrote:
> > > On Tue, Jun 8, 2021 at 1:17 PM Ferruh Yigit <ferruh.yigit@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 <tbogendoerfer@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: stable@dpdk.org
> > > > >
> > > > > Signed-off-by: Christian Ehrhardt <christian.ehrhardt@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.
> 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.
Marco Varlese June 17, 2021, 8:24 a.m. UTC | #7 
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.ehrhardt@canonical.com> wrote:
>>> On Thu, Jun 10, 2021 at 10:39 AM Christian Ehrhardt
>>> <christian.ehrhardt@canonical.com> wrote:
>>>> On Tue, Jun 8, 2021 at 1:17 PM Ferruh Yigit <ferruh.yigit@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 <tbogendoerfer@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: stable@dpdk.org
>>>>>>
>>>>>> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@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.
>
>
Christian Ehrhardt July 1, 2021, 8:23 a.m. UTC | #8 
On Thu, Jun 17, 2021 at 10:25 AM Marco Varlese <marco.varlese@suse.com> 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
> >> <christian.ehrhardt@canonical.com> wrote:
> >>> On Thu, Jun 10, 2021 at 10:39 AM Christian Ehrhardt
> >>> <christian.ehrhardt@canonical.com> wrote:
> >>>> On Tue, Jun 8, 2021 at 1:17 PM Ferruh Yigit <ferruh.yigit@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 <tbogendoerfer@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: stable@dpdk.org
> >>>>>>
> >>>>>> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@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.

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 July 1, 2021, 1:24 p.m. UTC | #9 
On Thu, Jul 1, 2021 at 10:23 AM Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
>
> On Thu, Jun 17, 2021 at 10:25 AM Marco Varlese <marco.varlese@suse.com> 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
> > >> <christian.ehrhardt@canonical.com> wrote:
> > >>> On Thu, Jun 10, 2021 at 10:39 AM Christian Ehrhardt
> > >>> <christian.ehrhardt@canonical.com> wrote:
> > >>>> On Tue, Jun 8, 2021 at 1:17 PM Ferruh Yigit <ferruh.yigit@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 <tbogendoerfer@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: stable@dpdk.org
> > >>>>>>
> > >>>>>> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@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.
>
> 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
Thomas Monjalon Oct. 25, 2021, 7:59 p.m. UTC | #10 
01/07/2021 15:24, Christian Ehrhardt:
> On Thu, Jul 1, 2021 at 10:23 AM Christian Ehrhardt
> <christian.ehrhardt@canonical.com> wrote:
> > On Thu, Jun 17, 2021 at 10:25 AM Marco Varlese <marco.varlese@suse.com> 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
> > > >> <christian.ehrhardt@canonical.com> wrote:
> > > >>> On Thu, Jun 10, 2021 at 10:39 AM Christian Ehrhardt
> > > >>> <christian.ehrhardt@canonical.com> wrote:
> > > >>>> On Tue, Jun 8, 2021 at 1:17 PM Ferruh Yigit <ferruh.yigit@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 <tbogendoerfer@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: stable@dpdk.org
> > > >>>>>>
> > > >>>>>> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@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.
> >
> > 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
diff mbox series

Patch

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)
 #define HAVE_TX_TIMEOUT_TXQUEUE
 #endif