01/07/2021 15:24, Christian Ehrhardt:
> On Thu, Jul 1, 2021 at 10:23 AM Christian Ehrhardt
> <christian.ehrha...@canonical.com> wrote:
> > On Thu, Jun 17, 2021 at 10:25 AM Marco Varlese <marco.varl...@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.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.
> >
> > 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
