DPDK patches and discussions
 help / color / mirror / Atom feed
From: Christian Ehrhardt <christian.ehrhardt@canonical.com>
To: Marco Varlese <marco.varlese@suse.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@intel.com>, dev <dev@dpdk.org>,
	 dpdk stable <stable@dpdk.org>,
	Thomas Bogendoerfer <tbogendoerfer@suse.de>,
	 "jcaamano@suse.com" <jcaamano@suse.com>,
	"snmohan83@gmail.com" <snmohan83@gmail.com>,
	"ndas@suse.de" <ndas@suse.de>
Subject: Re: [dpdk-dev] [PATCH] kni: fix compilation on SLES15-SP3
Date: Thu, 1 Jul 2021 15:24:09 +0200	[thread overview]
Message-ID: <CAATJJ0Lzy9mV-Je1uf2oOqFAgViaanjfJkW3tBtRRXm-qSH2Ug@mail.gmail.com> (raw)
In-Reply-To: <CAATJJ0+XK0j6tUp0bTnyZySQSuFGxTa13OqdxCGPYXFR6tumcQ@mail.gmail.com>

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



-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

  reply	other threads:[~2021-07-01 13:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02 14:33 Christian Ehrhardt
2021-06-04 13:02 ` Luca Boccassi
2021-06-08 11:17 ` Ferruh Yigit
2021-06-10  8:39   ` Christian Ehrhardt
2021-06-10 10:30     ` Christian Ehrhardt
2021-06-17  6:14       ` Christian Ehrhardt
2021-06-17  6:41         ` Thomas Monjalon
2021-06-17  8:24           ` Marco Varlese
2021-07-01  8:23             ` Christian Ehrhardt
2021-07-01 13:24               ` Christian Ehrhardt [this message]
2021-10-25 19:59                 ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAATJJ0Lzy9mV-Je1uf2oOqFAgViaanjfJkW3tBtRRXm-qSH2Ug@mail.gmail.com \
    --to=christian.ehrhardt@canonical.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jcaamano@suse.com \
    --cc=marco.varlese@suse.com \
    --cc=ndas@suse.de \
    --cc=snmohan83@gmail.com \
    --cc=stable@dpdk.org \
    --cc=tbogendoerfer@suse.de \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).