19.11.11 patches review and test

[Christian Ehrhardt]

On Tue, Dec 14, 2021 at 6:49 AM Kalesh Anakkur Purayil
<kalesh-anakkur.purayil at broadcom.com> wrote:

[snip]

>> > [Kalesh] Yes, i am seeing the same error. I used make command to build dpdk, not meson.
>> > The back ported commit you mentioned takes care of meson build only I think.
>> >
>>
>> I see, make build is failing, and yes the fix is only for the meson.
>> I will check the make build and will send a fix for it.
>
> [Kalesh]: looks like the below changes fixes the issue. I tried only on SLES15 SP3 and not on other SLES flavors.
>
> diff --git a/kernel/linux/kni/Makefile b/kernel/linux/kni/Makefile
> index 595bac2..bf0efab 100644
> --- a/kernel/linux/kni/Makefile
> +++ b/kernel/linux/kni/Makefile
> @@ -16,6 +16,16 @@ MODULE_CFLAGS += -I$(RTE_OUTPUT)/include
>  MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h
>  MODULE_CFLAGS += -Wall -Werror
>
> +#
> +# Use explicit 'source' folder for header path. In SUSE 'source' is not linked to 'build' folder.
> +#
> +ifdef CONFIG_SUSE_KERNEL
> +   KSRC = /lib/modules/$(shell uname -r)/source
> +   ifneq ($(shell grep -A 1 "ndo_tx_timeout" $(KSRC)/include/linux/netdevice.h | grep -o txqueue),)
> +      MODULE_CFLAGS += -DHAVE_TX_TIMEOUT_TXQUEUE
> +   endif
> +endif

Back in the day we tried various "is Suse and kernel version x.y"
approaches, but they failed as there was no clear version throughout
all of the Suse streams (leap, tumbleweed, sles) that worked well for
all.
This change here follows the upstream approach of "just check if it is there".

I've applied this to 19.11 and did test builds across various distributions:
1. no non-suse build changed
2. suse builds stayed as-is or improved
Formerly failing:
   openSUSE_Factory_ARM aarch64
   SLE_15  x86_64 -> now working
   openSUSE_Leap_15.3 x86_64 -> now working
   openSUSE_Tumbleweed  x86_64 -> still failing
Formerly working:
   SLE_12_SP4 x86_64 ppc64le -> still fine
   openSUSE_Factory_ARM armv7l  -> still fine
   openSUSE_Leap_15.2 x86_64  -> still fine

Past fixes always "inverted" the result, by fixing some but breaking others.
This new patch works in "not breaking any formerly working build" but
at the same time fixing a few builds.
Therefore -> applied & thanks!

I'll likely tag -rc2 before the end of the week.
The good thing is that (so far) we have:
1. a non functional change
2. a change fixing clang-13 builds (TBH only one of many needed clang13 issues)
3. a change fixing sles15SP3 builds

Due to those, no current ongoing tests will have to be restarted.
Whoever was able to build, can continue the current tests.
Whoever was blocked by SLES15SP3 or clang-13 had no tests other than a
failing build and can work with -rc2 then.
I'll explain the same in the mail about -rc2.

>  -include /etc/lsb-release
>
>  ifeq ($(DISTRIB_ID),Ubuntu)
>
> Regards,
> Kalesh

[snip]

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd