From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1004CA034C; Tue, 14 Dec 2021 15:46:53 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B5DD340041; Tue, 14 Dec 2021 15:46:52 +0100 (CET) Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by mails.dpdk.org (Postfix) with ESMTP id 2A0A54003C for ; Tue, 14 Dec 2021 15:46:51 +0100 (CET) Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id EEAFF3F205 for ; Tue, 14 Dec 2021 14:46:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1639493210; bh=6IzsO2A5fiioxO8cdfMCVyNUawjlCfNpO5B4m+yZbVs=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=sYWqi0f0tSg5lw/cE/glhjtAFWvUu0TJ51+O9fzV8+a26aP79AtrsSAd9JcDvSKDI 3bHiMqV9V7KUdjBMnH3EIOUjmmK57hGdiJdDAgYm6X4pEmuL5WNKoi6hb0+62em0Pb 6OcEDOxvQAEwzal1AcC1zSGi6s1zGXqfuVKXUX6ZaoaFvOd9bV/yYlrRvQE2J7RWNI 1DQAYEo4HF3q9kmUBSmle27n/GQuTtUq0Xt3I5dyAJ95vnSmc0oVir2fq4z+LBzrd5 6Uxb1cfAlJOQasRE7PO8w4SaEFUQ6OfTEo5RimMZqYIuhset4Ulbf/92/JkX/xTK9R NNtSlkPS9ZYfg== Received: by mail-qv1-f72.google.com with SMTP id fn12-20020ad45d6c000000b003bd9c921c0eso27201006qvb.21 for ; Tue, 14 Dec 2021 06:46:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6IzsO2A5fiioxO8cdfMCVyNUawjlCfNpO5B4m+yZbVs=; b=DpDI0F1632SvDJxX7LvfuDo6Q3E2I41bzgOaCpbtDwX1AyBzRqlLKFRrdt/bG2cgsJ 8ey/GqvunljVs6Q9+DSjl/Qk4HNlxAMUDt25FeVTWCAXS7GJ27yCKOEkhgPxnAxyqUAx f/PvzukHFB6n0LrbVzbiKHGY+8ox73Af/Wiur21OWo0WPz9gUAOLAvuAJ06hQ8fNOlYf gayt+Un01CIrfj3KFqc5PYbRoKrvvE52uWfm/mCcgWyHxaFCAqggF9QkA/SYy2+ytQVt VSOuDPAHTJHpMFshLOaARAvMOanzbH9r7pq+uIwrsR5lq0sDXQlY5AF/bK+1Ih8XA4CK fFqQ== X-Gm-Message-State: AOAM531WXa887jDdKRAyIziKm9jZ5U7wHnSMTb16RDkmrwX+eIJLLYBM kBq6WmLi2lK8rBjxt0EkGjujyLUCVMZ+VgwAZKXBEeaJH1Y7WRDkyBwoDNBOib7Z0pUFJVdQg/6 jS7bGdXT9ffyqk1k+umoh5mvOBKWGPZhuON6c X-Received: by 2002:a05:620a:25cf:: with SMTP id y15mr4419083qko.21.1639493209917; Tue, 14 Dec 2021 06:46:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJy+0VPijvxiMMSzGmreSE64zqvSHdBTu4SbqJB6IQQXgONEA2qyEJGjfcJmebVB7rVni7FyKomAoaDgpF8V8kc= X-Received: by 2002:a05:620a:25cf:: with SMTP id y15mr4419060qko.21.1639493209635; Tue, 14 Dec 2021 06:46:49 -0800 (PST) MIME-Version: 1.0 References: <20211209144315.3424225-1-christian.ehrhardt@canonical.com> <7bf4583f-c2de-0aa7-fb00-bf3e9ff8d99b@intel.com> <34e0a9a8-327e-0150-b18a-dc3bfdca7d11@intel.com> <43d82514-b3e0-1bbd-1351-f1221bfc53db@intel.com> <5ac74587-4a18-3e0b-f674-73f927a11f95@intel.com> <9f445304-f5d6-49a7-1f0f-65db8725d1ca@intel.com> In-Reply-To: From: Christian Ehrhardt Date: Tue, 14 Dec 2021 15:46:23 +0100 Message-ID: Subject: Re: 19.11.11 patches review and test To: Ferruh Yigit Cc: Kalesh Anakkur Purayil , Abhishek Marathe , Akhil Goyal , Ali Alnubani , David Christensen , Hariprasad Govindharajan , Hemant Agrawal , Ian Stokes , Jerin Jacob , John McNamara , Ju-Hyoung Lee , Kevin Traynor , Luca Boccassi , Pei Zhang , Raslan Darawsheh , Thomas Monjalon , benjamin.walker@intel.com, dpdk stable , dpdk-dev , pingx.yu@intel.com, qian.q.xu@intel.com, yuan.peng@intel.com, zhaoyan.chen@intel.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Dec 14, 2021 at 2:58 PM Christian Ehrhardt wrote: > > On Tue, Dec 14, 2021 at 2:10 PM Ferruh Yigit wrote: > > > > On 12/14/2021 11:39 AM, Christian Ehrhardt wrote: > > > On Tue, Dec 14, 2021 at 11:13 AM Ferruh Yigit wrote: > > >> > > >> On 12/14/2021 7:44 AM, Christian Ehrhardt wrote: > > >>> On Tue, Dec 14, 2021 at 6:49 AM Kalesh Anakkur Purayil > > >>> 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 > > >>> > > >> > > >> Thanks Kalesh for the fix, and thanks Christian for testing. > > >> > > >> I was expecting this approach will fix all builds, after patch only > > >> 'openSUSE_Tumbleweed' is failing, right? I will check it. > > > > > > As just discussed on IRC, yes and the log for that is at > > > https://build.opensuse.org/package/live_build_log/home:cpaelzer:branches:home:bluca:dpdk/dpdk-19.11/openSUSE_Tumbleweed/x86_64 > > > > > > It also is affected by an issue around -Werror=implicit-fallthrough, > > > so even with KNI fixed it likely is going to fail. > > > > > >> And I think you need the fix as a patch anyway, @Kalesh are you > > >> planning to send the patch? > > > > > > I don't need it, as I have already grabbed and preliminary added it: > > > https://github.com/cpaelzer/dpdk-stable-queue/commit/d43fa3e198c08a3a76d70f4565b31ad3ab5f29c4 > > > > > > But surely, once/If you come up with a full patch that also includes > > > tumbleweed I can replace it with yours. > > > > > > > 'tumbleweed' error is odd, it complains about macro being redefined, > > not sure why only in this platform we are getting an error. > > > > Macro is only defined in one place, but indeed header file included > > multiple times, one direct and one indirect, so macro defined multiple > > times but without value, so it should be OK and it is OK for other > > platforms, it is defined as: > > #define HAVE_TX_TIMEOUT_TXQUEUE > > > > Another option is that macro is defined in some other header file, > > although I think that is very unlikely, can you please test with > > below change to rule out that option: > > I'm testing that and will let you know in a bit ... Hi Ferruh, with your change the build now works. So indeed the symbol might have been defined elsewhere. https://build.opensuse.org/package/live_build_log/home:cpaelzer:branches:home:bluca:dpdk/dpdk-19.11/openSUSE_Tumbleweed/x86_64 It still fails later with the "-Werror=implicit-fallthrough=" but that is a different problem => https://bugs.dpdk.org/show_bug.cgi?id=907 Ferruh - are you ok if I merge your suggestion with the backport I got from Kalesh? > > diff --git a/kernel/linux/kni/compat.h b/kernel/linux/kni/compat.h > > index 664785674ff1..71846419f437 100644 > > --- a/kernel/linux/kni/compat.h > > +++ b/kernel/linux/kni/compat.h > > @@ -135,7 +135,7 @@ > > (defined(RHEL_RELEASE_CODE) && \ > > RHEL_RELEASE_VERSION(8, 3) <= RHEL_RELEASE_CODE) || \ > > (defined(CONFIG_SUSE_KERNEL) && defined(HAVE_ARG_TX_QUEUE)) > > -#define HAVE_TX_TIMEOUT_TXQUEUE > > +#define RTE_HAVE_TX_TIMEOUT_TXQUEUE > > #endif > > > > #if KERNEL_VERSION(5, 9, 0) > LINUX_VERSION_CODE > > diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c > > index c8bad5f197ca..7397de4659b2 100644 > > --- a/kernel/linux/kni/kni_net.c > > +++ b/kernel/linux/kni/kni_net.c > > @@ -623,7 +623,7 @@ kni_net_rx(struct kni_dev *kni) > > /* > > * Deal with a transmit timeout. > > */ > > -#ifdef HAVE_TX_TIMEOUT_TXQUEUE > > +#ifdef RTE_HAVE_TX_TIMEOUT_TXQUEUE > > static void > > kni_net_tx_timeout(struct net_device *dev, unsigned int txqueue) > > #else > > > > > > >>> 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 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd