Re: [dpdk-dev] [PATCH] kni: fix compilation on SLES15-SP3

[Marco Varlese <marco.varlese@suse.com>]

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.
>
>