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 6FEF7A0032 for ; Thu, 16 Dec 2021 08:22:27 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9C1A841142; Thu, 16 Dec 2021 08:22:25 +0100 (CET) Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) by mails.dpdk.org (Postfix) with ESMTP id 68BD74114D for ; Thu, 16 Dec 2021 08:22:24 +0100 (CET) Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) (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-0.canonical.com (Postfix) with ESMTPS id 5516F3FFD9 for ; Thu, 16 Dec 2021 07:22:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1639639343; bh=YIJsnBcNzl/ybKTKJqGvZEQVysjVYxbKXXXbx74xGIg=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=al6FxDub7Zys6yXe2zajsEFccQcstgdILVv/dgxC1zJ6iLk7zzSgqwChA6ktlzSep u7onsUdsBYyIVqE6cZN9lQhnVUr10B2zrywj3NFHq3fyXlko/yeYjQD/aXu9xj0ocZ KfD2xsgs8dQLvCUUM0wEbQ8/Igm+PrT5yLWCVgrt+o13bwrAELiMlN6WFq3UW63za4 9iNMqjRxU/2e6wX5Wt2zvW6e/15065KhjykgBDpiqVM6GPuV4MlvbAATF/nbVa6Qiu 4lOLm44PjxAqmY5e0DJEmgArQ5STEqmRIGsmd2DHyw24DbohGPaDrZRWQz5l79JOLq p6U9iSjhq3e/Q== Received: by mail-qk1-f197.google.com with SMTP id u8-20020a05620a454800b00468482aac5dso20413697qkp.18 for ; Wed, 15 Dec 2021 23:22:23 -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=YIJsnBcNzl/ybKTKJqGvZEQVysjVYxbKXXXbx74xGIg=; b=NRDim4RsWZYBPyoDR9mBF8IVTDzijyUYMglgWfaj/GNp3R5UlMV+V7/cZP1HX+QY/3 aeFM76jv5m+UKlW0rMmkKX94NwkuqdemqwnRnXKd8Oyaj8bzmuHQhlV0iCtIPhzpmL1T R/J4WFfcsgUFGJuAjtlhKhnNRJ8X0O4/2nJoy4Ci9MupSsGvMat5G6jueptniwUlJJle nfJBJe6qOlrJwTl+TkxEZ8IhcIh7R+Nxlq5DFjefHeqAL8FwoSK6vHM7a90u8/LeJLsT D0suli/XpXT1Z1+kD/rqtpgTRAufKAUukU1CIBqupefVEgAeGvWmzac0pxXe1zPzQlZO IQ7A== X-Gm-Message-State: AOAM532yXmlDctordUJaOApesn9FoFG26R2AMjemKUYz84G1wdAHFKFS gP1QmbyyR9vBD8WB1CEzUCye0aAhgDrj1+XqrGILu63x0POhZOSj8XlPU8pqnB7i8P0BC4Dum/i avnWxrTzVu4h6YtmE3Vcq501UqcWZRn/FAME3/WQY X-Received: by 2002:a05:6214:21ed:: with SMTP id p13mr14511705qvj.111.1639639342287; Wed, 15 Dec 2021 23:22:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJyalNUb8d3fI8zvo198xIU8VfntMW/MV8XP7lPcPa8n3upqMnUzHM6TDNsxPaxYPyqmxSoO9/egm1TuKQ7v7RM= X-Received: by 2002:a05:6214:21ed:: with SMTP id p13mr14511673qvj.111.1639639342029; Wed, 15 Dec 2021 23:22:22 -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> <04da027a-d9c0-5fe2-ec8c-1e72c66bfcbb@intel.com> <8a2eafeb-70d3-57ab-c192-2a6c41e183fc@intel.com> In-Reply-To: <8a2eafeb-70d3-57ab-c192-2a6c41e183fc@intel.com> From: Christian Ehrhardt Date: Thu, 16 Dec 2021 08:21:55 +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 , 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: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Wed, Dec 15, 2021 at 3:44 PM Ferruh Yigit wrote: > > On 12/15/2021 1:17 PM, Christian Ehrhardt wrote: > > On Tue, Dec 14, 2021 at 3:52 PM Ferruh Yigit wrote: > >> > >> On 12/14/2021 2:46 PM, Christian Ehrhardt wrote: > >>> 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. > >>> > >> > >> Interesting, this is self note to prefix 'RTE_' future macros. > > > > While generally an interesting Idea I do not know what I saw yesterday. > > I have rebuilt it three times today and must say that other than I > > said before - it does not work with RTE_*. > > > > This was more expected result :) > > Is there a way to debug that environment? Not that I'd know of. Get a local VM of the same would be my way :-/ @Luca - you came up with this CI platform for the LTS builds, do you know of a way to debug in-place? > > Actually even worse than before, with RTE_.. even opensuse_leap15.3 > > and SLES15 fail again :-/ > > > >>> 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 > >>> > >> > >> Yep, this is igb_uio error, I assigned the bug to myself and will look at it. > >> > >>> Ferruh - are you ok if I merge your suggestion with the backport I got > >>> from Kalesh? > >>> > >> > >> Sure. > >> But would you mind sending the final patch to the stable mail list as record? > >> Or I can do the same if you prefer? > >> > >>>>> 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